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From  the  Sponsor 


Changing  the  Game  in  Software  Assurance 


No  developer  or  application  manager  likes  to  learn  that  their  code 
was  hacked  and  their  applications  exploited.  Therefore, 

CROSSTALK  readers  who  manage  and  write  code  are  often  the 
strongest  advocates  of  “doing  the  right  thing,”  especially  when  it 
comes  to  software  assurance  (SwA).  That  is  why  the  DHS  is  proud  to 
sponsor  this  issue,  primarily  focused  on  SwA  Ga?ne-Changing  Tools  and 
Practices. 

Many  SwA  tools  focus  on  automatic  bug-finding,  the  first  stage  in  a  two- 
phase  process  where  the  tool  finds  bugs  and  the  human  then  corrects  them;  Dr. 

Yannick  Moy’s  article,  Static  Analysis  Is  Not  just for  Finding  Bugs,  argues  for  a  larg¬ 
er  view  of  SwA  by  looking  at  die  computing  properties  of  software. 

With  today’s  global  IT  software  supply  chain,  project  management  and  software/systems 
engineering  processes  must  explicidy  address  security  risks  posed  by  exploitable  software.  In 
Considering  Software  Supply  Chain  Risks,  Dr.  Robert  J.  Ellison  and  Dr.  Carol  Woody  point  out  that 
a  software  supply  chain  can  involve  a  combination  of  internal  development,  outsourced  devel¬ 
opment,  multiple  commercial  suppliers,  and  the  use  of  legacy  systems.  The  composite  system 
inherits  the  risk  of  SwA  failure  at  any  point  in  such  a  supply  chain.  The  authors  recommend 
three  practices:  1)  mitigation  of  items  on  a  CWE/SANS  Institute  Top  25  list  linked  to  detailed 
design  or  coding  practices,  2)  mitigations  associated  with  risk  analysis,  requirements,  architec¬ 
ture,  and  testing,  and  3)  employment  of  a  full  life-cycle  context  for  security  improvement. 

Two  articles  build  on  the  SwA  Automation  Protocols  from  MITRE’s  DHS-sponsored 
Making  Security  Measurable  program.  Studying  Software  I  Vulnerabilities  by  Dr.  Robin  A.  Gandhi, 
Dr.  Harvey  Siy,  and  Yan  Wu  points  to  the  potential  for  using  these  automation  protocols  to 
build  tools  for  developers.  Sean  Barnum’s  The  Balance  of  Secure  Development  and  Secure  Operations  in 
the  Software  Security  Equation  shows  how  these  protocols  enable  development  and  operations 
staffs  to  better  communicate  and  cooperate  to  secure  applications. 

Education  is  another  essential  arena  for  addressing  the  security  risks  posed  by  exploitable 
software.  Lt.  Col.  Thomas  A.  Augustine  (Ret.)  and  Dr.  Lori  L.  DeLooze  examine  Information 
Assurance  Applications  in  Software  Engineering  Projects  from  U.S.  Naval  Academy  student  capstone 
projects.  Dr.  Nancy  R.  Mead  and  Dr.  Dan  Shoemaker  detail  Two  Initiatives  for  Disseminating 
Software  Assurance  Knowledge :  Carnegie  Mellon’s  SwA  Master’s  program,  providing  an  explicit  cur¬ 
riculum  of  knowledge  and  skills  necessary  to  produce  a  well-educated  SwA  professional;  and 
the  University  of  Detroit  Mercy’s  efforts  to  give  every  instructor  in  a  computer-related  discipline 
access  to  validated  content  and  instructional  materials  that  can  be  easily  incorporated  into  exist¬ 
ing  courses. 

Online  readers  of  CROSSTALK  get  a  bonus  article:  Patti  Spicer’s  Gaining  Software  Assurance 
Through  the  Common  Criteria  gives  both  a  background  of  the  Common  Criteria  and  explains  how 
its  certification  process  provides  software  product  assurance. 

As  die  new  Director  of  the  National  Cyber  Security  Division,  part  of  my  responsibility  is  to 
advance  efforts  like  those  described  in  this  issue.  I  look  forward  to  working  with  talented  pro¬ 
fessionals  like  readers  of  CROSSTALK,  who  make  our  nation’s  software  and  applications 
resilient  and  secure. 
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Policies,  News,  and  Updates 


CrossTalk  Goes  All  Electronic: 
Turning  Necessity  into  Opportunity 


CROSSTALK  is  moving  to  an  all-electronic  format  beginning  with  our  November/December  2010  issue. 
Many  reasons  and  discussions  have  shaped  our  decisions  to  make  this  move,  with  budgets,  costs,  and  spon¬ 
sorships  having  a  major  impact. 

Understandably,  some  of  our  avid  readers  will  find  the  change  unwelcome. 

The  first  silver  lining  is  that  we  will  still  have  a  laid  out  version  of  CROSSTALK,  allowing  for  the  full  edi¬ 
tions  and  individual  articles  to  be  downloaded  in  PDF  form.  Secondly,  the  numbers  suggest  that  it’s  an  oppor¬ 
tune  time  for  changes: 

•  CROSSTALK’S  online  edition  averages  1.1  million  visitors  per  month,  while  our  hardcopy  subscribers — 
currently  less  than  1  percent  of  our  readership — has  remained  steady.  We  can  now  focus  our  mission  on 
the  methods  that  a  majority  of  our  readership  uses. 

•  CROSSTALK  is  making  every  effort  to  be  environmentally  conscious.  Eliminating  a  print  version  reduces 
our  global  footprint  in  tire  neighborhood  of  700,000  printed  pages  per  issue. 

Readers  will  also  notice  continuing  changes  to  our  Web  site.  These  improvements  will  aid  all  of  our  read¬ 
ers,  whether  they  are  seeking  the  current  issue  or  searching  our  issues  archive,  dating  back  to  1994. 

We  understand  tire  print  version  is  an  important  tool — the  passing  from  colleague  to  colleague,  tire  ear¬ 
marked  reference  copies  on  desks — it’s  what  CROSSTALK  has  always  been  about.  I’m  reminded  of  what  I 
saw  at  this  year’s  Systems  and  Software  Technology  Conference,  from  Hillel  Glazer’s  showing  off  of  our 
January/February  2010  CMMI  issue  to  Dr.  Robert  Cloutier’s  Plenary  Session  kudos  causing  a  run  on  the  May 
2005  edition.  Even  in  the  electronic  age,  our  print  versions  still  produce  a  significant  impact. 

But  we  have  to  change.  We  hope  future  sponsorship  increases,  and  with  that  a  return  to  distributing  our 
journal  to  the  tens  of  thousands  of  people  and  businesses  that  like  holding  CROSSTALKS  in  their  hands. 

Please  visit  <www.stsc.hill.af.mil/ crosstalk>  to  sign  up  for  an  electronic  notification  and  a  link  to  future 
CrossTalk  issues. 

We  thank  you  for  reading  CROSSTALK  and  ask  for  your  continued  support  in  this  transition. 


Kasey  Thompson 
CrossTalk  Publisher 
kasey.tliompson@liill.af.mil 
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Game-Changing  Tools  and  Practices 


Static  Analysis  Is  Not  Just  for  Finding  Bugs 

Dr.  Yannick  Moy 
AdaCore 


Static  analysis  tools  are  gaining  popularity  for  safeguarding  against  the  most  common  causes  of  errors  in  software.  The  main 
focus  of  these  tools  is  on  automatic  hug-finding — the  first  stage  in  a  two-phase  process  where  the  tool  finds  hugs  and  the  human 
then  corrects  them.  This  article  explains  that  such  a  goal  is  too  narrow  for  critical  software  assurance  (SwA).  Instead,  static 
analysis  tools  should  adopt  a  broader  perspective:  computing  properties  of  software. 


Static  analysis  tools  (see  the  sidebar  on 
page  7)  are  very  useful  for  finding  bugs. 
They  go  far  beyond  the  capabilities  of 
compilers  (warnings)  and  coding  standard 
checkers  to  which  they  are  directly  related. 
Like  compilers  when  they  generate  warn¬ 
ings,  static  analysis  tools  aim  to  detect  pos¬ 
sible  run-time  errors  (e.g,  buffer  over¬ 
flow)  and  logic  errors  (e.g.,  variables  not 
referenced  after  being  assigned).  Like  cod¬ 
ing  standard  checkers,  static  analysis  tools 
sometimes  allow  users  to  define  their  own 
set  of  patterns  to  flag.  But  static  analysis 
tools  generally  perform  much  more 
sophisticated  analyses  than  is  typically 
found  in  compilers  and  coding  standard 
checkers  (e.g.,  looking  at  global  context 
and  keeping  track  of  data  and  control 
flow). 

The  appeal  of  these  tools  is  immedi¬ 
ate,  providing  an  almost  yes/ no  answer  to 
very  hard  problems  (termed  undecidahle  in 
mathematical  terms) .  But  while  you’re  ask¬ 
ing  Are  there  any  bugs  in  this  code?,  the  tool  is 
actually  answering  a  subtly  different  ques¬ 
tion:  Have  any  bugs  been  detected  in  this  code? 
Thus,  when  a  tool  answers  no  problems,  it 
means  that  it  couldn’t  detect  any  bugs;  it 
doesn’t  mean  that  the  code  has  no  bugs. 
Further,  the  actual  question  should  be: 
Have  any  shallow /  common  bugs  been  detected  in 
this  code?  As  explained  by  a  team  at  soft¬ 
ware  integrity  company  Coverity:  “errors 
found  with  little  analysis  are  often  better” 
because  they  are  clear  errors  that  a  human 
reviewer  will  more  likely  understand  [1]. 

That  is  the  catch.  Static  analysis  tools 
are  not  compilers  whose  output  (object 
code)  rarely  needs  to  be  inspected.  They 
produce  results  for  humans  to  review.  At 
the  very  least,  a  human  needs  to  under¬ 
stand  the  problem  being  reported — and 
also,  in  most  cases,  the  reason  for  the 
report — in  order  to  assess  what,  if  any, 
correction  to  make. 

Focusing  on  Human-Readable 
Output 

Because  humans  ultimately  label  each 
problem  reported  by  a  static  analyzer  as 


either  a  real  error  os  a  false  alarm  whose  ratio 
is  used  to  evaluate  the  quality  of  a  tool, 
commercial  tools  strive  to  present  the  user 
with  understandable  warnings  supported 
by  explanations.  Even  trivial  changes  to 
the  messages  may  have  a  large  impact.  In 
my  own  experience  working  on  the  static 
analyzer  PolySpace,  I  was  quite  surprised 
by  the  positive  response  from  customers 
on  what  seemed  to  be  simply  a  cosmetic 
change.  Messages  for  warnings  had  been 
reworded  to  reflect  the  associated  likeli¬ 
hood,  so  that  the  message  out  of  bounds 
array  index  associated  with  certain  (red) 
and  possible  (orange)  warnings  was  now 
turned  into  Error:  array  index  is  out  of 
bounds  and  Warning:  array  index  may  be  out  of 
bounds. 

The  short  message  is  usually  accompa¬ 
nied  by  a  link  to  a  page  describing  the 
intent  of  the  checker  being  exercised,  and 
the  typical  errors  that  it  finds.  Some  static 
analyzers  also  display  more  contextual 
information  that  helps  the  user  in  diag¬ 
nosing  the  problem.  For  example,  PREfix, 
an  internal  tool  at  Microsoft,  displays 
whether  the  problem  occurs  inside  a  loop 
or  not,  the  depth  of  calls  that  exhibit  the 
problematic  execution,  etc. 

As  most  problems  only  show  up  in 
some  executions  reaching  a  particular  pro¬ 
gram  point,  a  useful  piece  of  information 
is  the  execution  path  leading  to  these 
problematic  executions.  Static  analyzers 
typically  display  such  paths  by  coloring  the 
lines  of  code  defining  the  path  (e.g,  the 
first  line  of  each  block  of  code  involved). 
The  path  may  involve  function  calls,  in 
which  case  the  user  can  usually  unfold  the 
call  to  follow  the  path.  Some  static  analyz¬ 
ers  even  display  contextual  explanations 
along  the  path  to  help  follow  the  rationale 
for  a  given  warning. 

Still,  as  Coverity’s  team  puts  it, 
“explaining  errors  is  often  more  difficult 
than  finding  them”  [1],  This  means  that  a 
balance  is  found  in  practice  between 
explaining  displayed  warnings  and  hiding 
those  warnings  that  cannot  be  so  easily 
explained.  As  a  result,  real  errors — which 


are  detected  but  are  complex  to  explain — 
may  fail  to  be  reported:  “For  many  years 
we  gave  up  on  checkers  that  flagged  con¬ 
currency  errors;  while  finding  such  errors 
was  not  too  difficult,  explaining  them  to 
many  users  was”  [1]. 

Static  Analysis  for  Critical 
SwA 

Finding  bugs  with  static  analysis  tools, 
even  simple  bugs  that  testing  would  catch 
is,  of  course,  useful.  Embedded  systems 
expert  Jack  G.  Ganssle  advocates  doing 
inspections  before  testing  because  inspec¬ 
tions  are  20  times  cheaper  than  writing 
tests:  “It  is  just  a  waste  of  company 
resources  to  test  first”  [2],  As  human  time 
is  far  more  expensive  than  CPU  time,  the 
same  argument  shows  that  static  analysis 
should  be  performed  before  inspections 
or  testing,  even  for  finding  simple  bugs. 

However,  the  nets  that  static  analysis 
tools  are  using  to  catch  bugs  have  a  large 
mesh,  too  coarse  for  critical  SwA.  One 
example  is  integer  overflow:  adding  two 
large  positive  integers  and  getting  a  nega¬ 
tive  integer  as  a  result.  These  are  rather 
unimportant  bugs  for  most  commercial 
static  analyzers,  and  are  usually  not  even 
advertised  on  the  list  of  vulnerabilities 
they  look  for.  There  is  some  rationale  as  to 
why  integer  overflow  is  not  a  high  priority. 
At  Microsoft  Research,  I  worked  with  a 
team  that  augmented  PREfix  with  the  abil¬ 
ity  to  detect  integer  overflow  bugs — and 
then  applied  it  to  a  large  Microsoft  code- 
base  comprising  several  million  lines  of  C 
and  C++  [3],  The  tool  returned  with  tens 
of  thousands  of  possible  integer  over¬ 
flows — and  almost  all  of  them  were 
intended  or  benign.  With  special  heuristics 
to  hide  most  false  alarms,  the  tool  returned 
with  many  fewer  warnings  (still  hundreds). 
Three  days  of  reviewing  warnings  finally 
uncovered  1 5  serious  bugs,  most  of  which 
were  related  to  security  issues.  Relying  on 
user  review  to  find  a  few  serious  bugs 
amidst  a  large  number  of  warnings  is  not 
the  image  that  commercial  static  analyzers 
are  trying  to  achieve. 
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Static  Analysis  for  Automated 
Code  Review 

Instead  of  advocating  a  fully-automated 
approach  that  considers  human  review  as 
a  bottleneck  in  the  application  of  static 
analysis,  some  have  taken  the  opposite 
view  and  regard  static  analysis  as  a  mecha¬ 
nism  that  can  expedite  manual  code 
review. 

Brian  Chess  and  Jacob  West  from 
Fortify  Software  devote  a  complete  chap¬ 
ter  in  [4]  to  static  analysis  as  part  of  the 
code  review  process.  They  consider  warn¬ 
ings  issued  by  static  analysis  tools  as  clues 
drat  a  non-trivial  safety  or  security  argu¬ 
ment  has  to  be  made  by  a  human  review¬ 
er,  based  on  the  fact  that  “static  analysis 
tools  often  report  a  problem  when  they 
become  confused  in  die  vicinity  of  a  sen¬ 
sitive  operation”  [4],  They  also  insist  that, 
whenever  possible,  a  problem  found  by 
code  review  that  is  not  reported  by  the 
tool  should  be  the  basis  for  a  new  custom 
rule  in  the  static  analyzer.  Although  many 
tools  supply  an  application  programming 
interface  for  defining  such  custom  rules,  it 
is  not  likely  that  most  errors  found  during 
code  review  can  be  easily  encoded  into 
such  rules  (keep  in  mind  diat  several  orga¬ 
nizations  can  create  custom  checkers). 

Tucker  Taft  and  Robert  Dewar  have 
gone  further,  explaining  how  to  leverage 
static  analysis  tools  for  automated  code 
review  [5],  This  requires  a  way  to  query 
die  internal  information  computed  by  the 
tool  instead  of  just  the  warnings  it  issues. 
They  show  how  to  conduct  a  code  review 
of  inputs  and  outputs,  preconditions  and 
postconditions,  etc.,  based  on  information 
generated  by  static  analyzer  CodePeer. 
Undoubtedly,  making  static  analysis  a 
partner  in  code  review  presents  many 
questions  concerning  the  interaction 
between  the  tool  and  die  reviewer:  One 
must  determine  how  much  information  to 
display,  how  to  display  it,  and  which 
queries  should  have  displayed  the  infor¬ 
mation.  So  far,  static  analysis  tools  have 
largely  stayed  away  from  this  issue  because 
of  die  difficulties  in  dealing  with  the  large 
amount  of  information  available. 

However,  combining  static  analysis 
with  code  review  holds  the  promise  of 
each  method  complementing  the  other, 
since  their  strengths  are  in  different  areas. 
Tools  are  deterministically  sound  and 
unsound  (whether  by  design  or  through 
errors  in  the  tool  itself  or  in  its  setup), 
while  humans  are  unpredictably  sound 
and  unsound.  I  recently  co-conducted  a 
very  small  experiment  to  compare  the 
results  of  static  analysis  and  code  review 
for  finding  bugs  in  a  Tokeneer  system  [6] 


whose  security  properties  were  formally 
verified.  The  results  of  this  experiment 
suggest  that  each  method  catches  bugs  the 
other  method  misses. 

Focus  on  Humans,  Not  on 
Bugs 

Orienting  static  analysis  towards  automa¬ 
tion-assisted  code  review  requires  shifting 
die  focus  from  finding  bugs  to  helping  a 
human  understand  various  issues  about 
die  code,  from  data-flow  to  exception 
handling  to  proper  input  validation.  This 
does  not  mean  abandoning  warnings.  On 
one  hand,  tools  are  very  good  at  systemat¬ 
ically  detecting  a  clearly  defined  problem, 
whereas  humans  make  errors.  On  the 
other  hand,  tools  cannot  easily  deal  with 
die  specific  project  issues  or  translate 
informal  specifications  into  code  verifica¬ 
tion  activities.  Michael  D.  Ernst  believes 
diat  “humans  are  remarkably  resilient  to 
partially  incorrect  information,  and  are 
not  hindered  by  its  presence  among  (a  suf¬ 
ficient  quantity  of)  valuable  information” 

m- 

The  idea  is  to  automate  all  the  things 
diat  can  be  automated,  but  no  more.  With 
enough  eyes,  all  bugs  are  shallow.  We  can¬ 
not  say  the  same  about  enough  tools.  The 
choice  of  what  is  and  is  not  important  is 
best  left  to  a  human  to  decide,  provided 
suitable  user  interactions  are  built  into  the 
tools.  The  problem  is  diat  static  analyzers 
targeted  at  bug-finding  may  not  be  so  easy 
to  re-architect  for  answering  queries  from 
a  user.  Many  of  these  tools  only  consider 
sets  of  execution  paths  that  do  not  cover 
all  cases;  dierefore,  they  may  not  easily 
provide  information  on  all  executions. 

Tools  like  PolySpace  and  Frama-C  dis¬ 
play  ranges  of  integer  variables  (and 
pointer  variables  for  Frama-C)  on 
demand:  When  the  user  puts  die  focus  on 
a  variable  in  die  code,  the  range  corre¬ 
sponding  to  all  die  possible  values  of  this 
variable  (in  all  executions)  is  displayed  in  a 
tool-tip  or  in  a  side  panel.  PolySpace  uses 
die  same  kind  of  interaction  to  display  all 
die  information  it  computes  about  possi¬ 
ble  run-time  errors;  it  is  emphasized  by 
coloring  die  code  using  the  standard  con¬ 
vention  of  green  for  ok,  orange  for  ivarn- 
ing,  and  red  for  error. 

Static  Analysis  for  Computing 
Properties 

An  absence  of  run-time  errors  is  die  first 
property  that  comes  to  mind  when  talking 
about  static  analyzers.  Most  tools  cannot 
compute  this  property,  as  they  are 
designed  to  report  only  a  subset  of  all 
possible  errors  and  analyze  only  a  subset 


of  all  possible  executions.  To  the  best  of 
my  knowledge,  only  three  commercial 
tools  compute  diis  property:  the  Poly¬ 
Space  and  CodePeer  tools,  and  the 
SPARK  programming  language.  By  focus¬ 
ing  on  humans  rather  than  bugs,  all  three 
have  found  ways  to  solve  die  false  alarm 
problem:  PolySpace  colors  the  code  and 
lets  users  query  individual  program  points 
for  possible  run-time  errors;  CodePeer 
partitions  warnings  into  three  buckets 
(high,  medium,  low)  with  low  warnings 
only  presented  on  user  request;  and 
SPARK  imposes  enough  restrictions 
(checked  by  static  analysis)  that  the  false 
alarm  rate  is  low  (e.g,  there  can  be  no  read 
of  an  uninitialized  variable).  All  of  these 
tools  also  allow  recording  manual  analysis 
of  warnings  for  reuse  when  the  code  is 
reanalyzed  after  being  modified. 

Absence  of  run-time  errors  is  not  the 
only  property  of  interest  in  critical  SwA. 
In  fact,  it  is  rather  die  least  interesting 
property  (things  behave  as  they  are  writ¬ 
ten),  except  that  it  must  hold  in  order  for 
the  program  to  respect  any  odier  proper¬ 
ty,  and  it  could  ideally  be  verified  from 
source  code  only  without  any  user  guid¬ 
ance.  Absence  of  run-time  errors  is  some¬ 
times  framed  as  program  correctness, 
which  tends  to  boost  its  importance. 

In  a  recent  position  paper  [8],  software 
engineering  pioneer  David  Lorge  Parnas 
warns  diat  this  abstract  notion  of  correct¬ 
ness  makes  no  sense  in  practice: 
“Correctness  is  not  the  issue.”  Indeed, 
correctness  is  always  relative  to  a  given 
specification  and  every  non-trivial  specifi¬ 
cation  is  wrong,  whedier  it  is  formal  or 
informal.  The  usual  wrongness  is  being 
incomplete.  This  is  especially  true  for  for¬ 
mal  specifications,  because  no  existing 
formal  language  can  express  all  the  prop¬ 
erties  we  expect  from  a  correctly  operating 
system,  in  particular  for  embedded  soft¬ 
ware  that  interacts  with  die  outside  world. 
As  an  example,  a  correct  compiler  is  one 
that  must  satisfy  a  number  of  require¬ 
ments,  including  the  issuing  of  useful 
error  messages.  No  formal  language  can 
express  this  specification.  Instead  of  cor¬ 
rectness  proofs,  Parnas  urges  static  analy¬ 
sis  tool  writers  to  focus  on  property  calcu¬ 
lation,  which  is  the  norm  in  other  engi¬ 
neering  fields. 

We  are  interested  in  two  types  of 
properties: 

•  Functional  properties  like  values,  rela¬ 
tions,  preconditions,  postconditions, 
and  dependencies. 

•  Non-functional  properties  like  cover¬ 
age,  memory  footprint,  worst-case 
execution  time  (WCET),  and  profiling. 

Most  static  analyzers  are  already  capable 
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What  Is  a  Static  Analysis  Tool? 

A  static  analysis  tool  (or  static  analyzer)  has  three  major  characteristics: 

•  Its  input  is  the  source  code  for  a  program  in  a  programming  language. 

•  It  analyzes  the  program’s  structure  without  executing  the  program. 

•  As  its  primary  function,  the  tool  outputs  information  that  is  relevant  to  humans 
developing  or  maintaining  the  program. 

This  general  definition  includes  tools  such  as  coding  standard  checkers,  bugfinders,  and 
test  case  generators. 

Many  static  analysis  tools  attempt  to  detect  problematic  constructs.  Ideally,  such  a 
tool  should  identify  all  constructs  in  a  given  program — and  only  those  constructs 
encountering  the  problem  during  execution.  Unfortunately,  mathematical  com¬ 
putability  theory  shows  that  it  is  impossible  to  produce  such  a  tool  for  analyzing  arbi¬ 
trary  programs  in  any  nontrivial  programming  language.  So,  in  practice,  a  tool  will  suf¬ 
fer  from  either  one  or  both  of  these  deficiencies: 

•  Failure  to  detect  a  problem,  yielding  what  is  (perhaps  confusingly)  known  as  a  false 
negative. 

•  Mistakenly  flagging  a  correct  construct  as  a  problem,  yielding  a  false  alarm 
(known  in  the  literature  as  a  false  positive). 

A  tool  that  does  not  generate  false  negatives  is  said  to  be  sound.  A  tool’s  precision 
is  a  measure  of  its  ability  to  avoid  generating  false  positives.  Soundness  and  precision 
are  tradeoffs,  so  the  challenge  for  a  tool  provider  is  to  strike  an  appropriate  balance. 


of  generating  functional  information 
because  they  internally  compute  program 
invariants  that  are  predicates  describing 
some  constraints  respected  by  the  pro¬ 
gram  (e.g.,  the  fact  that  variable  X  is  posi¬ 
tive  at  some  point,  or  more  complex  rela¬ 
tions  between  variables  like  linear  inequal¬ 
ities  and  Boolean  combinations  of  such 
inequalities  that  hold  at  some  point). 
Preconditions  and  postconditions  are  spe¬ 
cial  kinds  of  invariants  that  are  particular¬ 
ly  interesting,  because  they  make  function 
interfaces  explicit. 

The  first  problem  is  that  a  static  ana¬ 
lyzer  may  compute  a  large  number  of  such 
invariants,  most  of  which  are  not  of  inter¬ 
est  to  the  user.  As  already  mentioned,  one 
solution  is  to  let  die  user  indicate  which 
invariants  are  of  interest.  Some  tools 
already  display  the  ranges  of  values  taken 
by  variables  when  a  user  selects  such  a 
variable  in  the  program.  Ideally,  we  would 
like  to  provide  an  arbitrary  expression,  say 
X  +  Y,  and  ask  the  static  analyzer  for  all 
invariants  at  a  specific  program  point  that 
mentions  this  expression. 

A  second  problem  is  that  many  static 
analyzers  do  not  exactly  compute  invari¬ 
ants,  either  because  they  analyze  only  one 
path  (or  set  of  paths)  at  a  time,  or  because 
they  perform  unsound  simplifications 
during  their  analysis.  In  the  former  case, 
die  predicate  that  characterizes  the  path 
(or  die  set  of  paths)  analyzed  is  usually  not 
easily  readable,  so  simply  outputting 
invariants  of  die  form  predicatefor-the-path 
implies  invariantfor-the-path  is  unlikely  to  be 
useful.  Instead,  we  can  imagine  diat  the 
path  (or  the  set  of  padis)  is  displayed  by 
highlighting  appropriate  lines  in  the 
source  code  (as  is  already  done  for  warn¬ 
ings) — and  that  only  the  invariant  part  is 
displayed.  Even  in  the  case  where  die  sta¬ 
tic  analyzer  performs  unsound  simplifica¬ 
tions  (possibly  missing  a  real  error),  giving 
access  to  the  internal  invariants  may  help 
users  understand  the  simplifications  per¬ 
formed  by  the  tool.  When  looking  for 
integer  overflow  bugs  in  a  large  codebase 
at  Microsoft,  I  found  it  very  useful  to  have 
access  to  the  models  computed  by  PREfix 
for  each  function.  These  models  gave  the 
invariants  at  function  exit  (postconditions) 
computed  by  the  tool  for  a  set  of  paths 
described  by  invariants  at  function  entry 
(preconditions).  This  was  critical  to  quick¬ 
ly  discard  warnings  caused  by  an  incorrect 
model  computed  by  the  tool,  which  made 
it  possible  to  concentrate  on  actual  errors. 

Some  static  analyzers  also  compute 
non-functional  properties  (i.e.,  properties 
that  are  not  related  to  the  correctness  of 
die  program’s  computations).  Many  static 
analyzers  warn  about  dead  code,  which  is 


die  same  property  as  code  coverage,  only 
seen  from  the  other  direction.  Aldiough 
general  coverage  seems  hard  to  attain  by 
static  analysis,  unit  coverage  that  considers 
die  coverage  of  a  function’s  constructs  for 
all  possible  calling  contexts  (and  thus  all 
values  of  inputs)  is  much  more  feasible. 
Again,  mapping  the  results  of  the  analysis 
onto  die  source  code  provides  the  best 
user  interaction  here.  Generating  tests 
whose  execution  shows  a  line  of  code  is 
also  a  constructive  way  to  compute  the 
property  that  a  line  of  code  is  not  dead. 

Expanding  on  this  idea,  we  can  imag¬ 
ine  giving  a  predicate  at  a  program  point, 
say  X  <  Y,  and  asking  the  static  analysis 
tool  to  produce  a  counterexample.  This  is 
a  very  efficient  way  to  make  progress 
when  the  tool  does  not  generate  an  invari¬ 
ant  which,  according  to  the  user,  should 
hold.  Without  such  interactions,  the  user 
is  usually  left  wondering  if  die  tool  was 
not  clever  enough  to  prove  the  property — 
or  if  it  holds  at  all.  Additionally,  seeing  the 
actual  counterexample  (instead  of  only 
knowing  there  is  one)  greatly  facilitates 
understanding  of  the  problem.  What  is 
important  here  is  the  user  interaction, 
which  allows  very  quick  feedback  on  a 
question  that  die  user  finds  interesting. 

Specialized  static  analysis  tools  already 
provide  information  such  as  memory 
footprints  and  WCET.  For  example, 
Airbus  is  using  these  tools  to  help  certify 
their  programs  at  the  highest  levels  of  the 
DO-178  avionics  safety  standard  [9], 
However,  not  much  work  has  been  done 
with  these  tools  to  provide  a  rich  user 
interaction  at  die  function  level. 

New  ways  of  interacting  with  static 


analysis  tools  are  desirable  and  possible. 
As  a  very  simple  example,  some  integrated 
development  environments  (IDEs)  can 
display  die  shortest  path  in  the  call  graph 
between  two  functions  when  a  user  asks 
whether  one  can  be  called  from  the  odier. 
Odier  IDEs  highlight  entities  based  on 
syntactic  categories,  triggered  when  the 
user  puts  the  cursor  on  an  entity.  Those 
are  the  kinds  of  useful  interactions  that 
static  analyzers  should  aim  for. 

Conclusion 

The  current  emphasis  on  static  analysis 
will  not  necessarily  provide  the  tools  that 
are  needed  for  critical  SwA,  which  is  based 
on  human  assessment  of  fitness-for-purpose. 
Useful  tools  are  those  that  compute 
human-readable  properties  of  the  soft¬ 
ware,  providing  reviewers  with  much 
deeper  information  than  is  currently  avail¬ 
able.  The  Agile  Manifesto  [10]  correctly 
recognizes  that  individuals  and  interac¬ 
tions  should  be  our  main  focus  for  creat¬ 
ing  useful  processes  and  tools. 

One  static  analysis  vendor  goes  as  far 
as  to  admit:  “No  one  wants  to  be  on  the 
hot  seat  when  a  critical  vulnerability  is 
exploited  in  the  field  or  when  a  coding 
mistake  causes  product  recalls,  brand 
damage,  or  revenue  losses.”  I  do  not  think 
that  static  analysis  provides  the  kind  of 
insurance  suggested  in  [11];  like  other  sys¬ 
tems  assurance,  critical  SwA  is  not  princi¬ 
pally  a  matter  of  tools,  but  a  matter  of 
“leadership,  independence,  people,  and 
simplicity”  [12]. 

Static  analysis  for  code  review  is  cer¬ 
tainly  a  very  promising  venue  for  critical 
SwA.  Looking  even  further,  static  analysis 
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Software  Defense  Application 

The  defense  industry — as  evidenced  by  projects  such  as  Software  Assurance  Metrics 
and  Tool  Evaluation — is  paying  significant  attention  to  static  analysis  tools.  This  arti¬ 
cle  helps  DoD  decision-makers  and  developers  assess  and  select  static  analysis  tools 
that  meet  their  safety  and  security  requirements. 


used  during  development  (e.g.,  for  code 
review  preparation)  can  help  a  program¬ 
mer  understand  complex  behaviors  and 
detect  subtle  mistakes — like  a  “buddy” 
does  in  pair  programming.  In  other  words, 
static  analysis  for  humans.  ♦ 
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Considering  Software  Supply  Chain  Risks 
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As  outsourcing  and  commercial  product  use  increase,  sipply  chain  risk  becomes  a  growing  concern  for  software  acquisitions. 
Hardware  supply  chain  risks  include  manufacturing  and  delivery  disruptions  and  the  substitution  of  counterfeit  or  substan¬ 
dard  components.  Software  supply  chain  risks,  usually  during  development,  include  third-party  product  tampering  or  the  intro¬ 
duction  of  exploitable  software  defects.  This  article  identifies  several  current  practices  that  can  be  incorporated  in  an  acquisi¬ 
tion  to  reduce  those  risks. 


Commercial  software  is  not  defect-free. 

There  are  any  common  defects  such 
as  improper  input  validation,  as  defined  by 
the  Common  Weakness  Enumeration 
(CWE),  The  MITRE  Corporation’s  list  of 
software  weakness  types  [1],  These  weak¬ 
nesses  can  be  readily  exploited  by  unau¬ 
thorized  parties  to  alter  the  security  prop¬ 
erties  and  functionality  of  software  for 
malicious  intent.  MITRE,  in  collaboration 
with  the  SANS  Institute,  publishes  a  year¬ 
ly  list  of  the  Top  25  Most  Dangerous 
Programming  Errors  [2].  Such  defects  can 
be  accidentally  or  intentionally  inserted 
into  software,  and  subsequent  acquirers 
and  users  have  limited  ways  of  finding  and 
correcting  these  defects  to  avoid  exploita¬ 
tion. 

A  report  by  application  security  com¬ 
pany  Veracode  [3]  draws  on  the  analysis  of 
billions  of  lines  of  code  and  thousands  of 
applications  that  they  have  analyzed.  Their 
overall  finding  is  that  most  software  is  very 
insecure.  Regardless  of  software  origin,  58 
percent  of  all  applications  submitted  for 
verification  did  not  achieve  an  acceptable 
security  score  for  its  assurance  level  upon 
first  submission  to  Veracode  for  testing. 
Table  1  has  the  results  (by  source)  of  soft¬ 
ware  tested  against  the  2009  CWE /SANS 
Institute  Top  25  list  [4];  it  shows  the  per¬ 
centage  of  submitted  software  that  passed 
the  security  test  on  the  first  trial.  As  60  to 
70  percent  of  the  tested  software  failed 
against  easily  remedied  weaknesses,  one  of 
Veracode’s  findings  was  the  lack  of  devel¬ 
oper  education  and  motivation  on  secure 
coding. 

Software  Supply  Chain 
Complexity 

There  has  been  extensive  analysis  of  sup¬ 
ply  chains  for  delivery  of  physical  materi¬ 
al,  an  analysis  based  on  data  collection 
over  decades  of  practice.  The  lack  of  an 
equivalent  base  of  practice  and  data  col¬ 
lection  for  software  has  severely  limited 
the  analysis  and  response  to  software  sup¬ 
ply  chain  risks. 


Most  supply  chains  are  not  a  single  link 
between  an  acquirer  and  a  supplier.  A  more 
complex  supply  chain  (such  as  that  shown 
in  Figure  1  on  the  next  page)  can  involve  a 
combination  of  internal  development,  out¬ 
sourced  development,  multiple  commercial 
suppliers,  and  legacy  system  usage.  The 
composite  system  inherits  the  risk  of  a  soft¬ 
ware  assurance  (SwA)  failure  at  any  point  in 
such  a  supply  chain.  The  acquirer  and  the 
primary  supplier  have  limited  visibility  of 
the  capabilities  of  deeply-nested  sub-suppli¬ 
ers.  Supply  chain  risks  can  be  reduced  but 
not  eliminated.  Once  software  is  deployed, 
residual  supply  chain  risk  identification  and 
mitigation  become  a  continuing  responsibil¬ 
ity  for  the  acquiring  organization. 

Software  supply  chain  risk  considera¬ 
tions  must  continue  in  sustainment.  An 
assessment  done  as  part  of  the  initial 
acquisition  for  a  commercial  component 
is  valid  only  at  that  time.  A  commercial 
software  component  can  easily  be 
deployed  for  five  years  or  longer.  During 
that  period,  the  following  can  happen: 

•  New  attack  techniques  and  software 
weaknesses  appear. 

•  Changes  in  acquirer  usage  activate 
product  features  with  weaknesses  that 
have  not  been  considered  in  earlier 
assessments. 

•  A  sequence  of  product  upgrades  that 
add  features  or  change  design  can 
invalidate  a  risk  assessment. 

•  Changes  occur  in  tire  risk  factors  used 
in  initial  vendor  and  product  assess¬ 
ment  (e.g.,  corporate  merger,  subcon¬ 
tractors,  corporate  policies  and  staff 
training,  or  in  the  corporate  software 
development  process). 

•  Product  criticality  increases  with  new 
or  expanded  usage. 

Mitigating  Common  Software 
Weaknesses  in  the  Supply  Chain 

Addressing  the  appearance  of  common 
software  weaknesses  introduced  in  a  sup¬ 
ply  chain  requires  knowing  where  to  look 
and  what  to  look  for.  Discussions  of  sys¬ 
tem  security  often  include  firewalls, 


authentication  issues  (such  as  password 
strength),  or  authorization  mechanisms 
(such  as  role-based  access  controls). 
Application  security  has  often  been 
ignored,  in  part  because  of  the  faulty 
assumption  that  firewalls  and  other 
perimeter  defenses  can  protect  the  func¬ 
tional  code.  The  problem  is  further  com¬ 
pounded  as  application  developers  with¬ 
out  specific  security  training  are  typically 
unaware  of  the  ways  their  software,  while 
meeting  functional  requirements,  could  be 
compromised.  Security  software — such  as 
a  firewall  or  a  password  management 
component — is  usually  subject  to  an  inde¬ 
pendent  security  assessment  that  consid¬ 
ers  the  development  history  as  well  as  the 
design  and  operational  context.  There  is 
no  equivalent  effort  applied  to  the  securi¬ 
ty  of  application  components. 

The  pervasiveness  of  easily  remedied 
weaknesses  (as  observed  by  Veracode) 
provides  a  simple  attack  vector  that  is  eas¬ 
ily  exploited.  A  first  step  should  be  the 
elimination  of  the  most  pervasive  com¬ 
mon  weaknesses,  particularly  from 
acquired  application  software. 

There  is  currently  insufficient  practice 
data  to  identify  best  practices  that  could 
be  required  of  suppliers,  but  our  observa¬ 
tion  of  current  practice  suggests  activities 
that  can  improve  confidence  in  a  software 
supply  chain  [5], 

Security  for  application  software  is  get¬ 
ting  increased  commercial  attention.  In 
2006,  Microsoft  established  their  Security 
Development  Lifecycle  (SDL),  which 
served  as  a  starting  point  for  other  efforts 
[6],  Today,  more  than  25  large-scale  appli¬ 
cation  software  security  initiatives  are 


Table  1:  CITE /SANS  Top  25  Compliance 


Software  Source 

Acceptable 

Outsourced 

6% 

Open  Source 

39% 

Internally  Developed 

30% 

Commercial 

38% 
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under  way  in  organizations  as  diverse  as 
multinational  banks,  independent  software 
vendors,  the  U.S.  Air  Force,  and  embed¬ 
ded  systems  manufacturers.  The  Software 
Assurance  Forum  for  Excellence  in  Code, 
an  industry-led  non-profit  organization 
that  focuses  on  the  advancement  of  effec¬ 
tive  SwA  methods,  published  a  report  on 
secure  software  development  [7],  In  2009, 
the  first  version  of  the  Building  Security 
In  (BSI)  Maturity  Model  [8]  (BSIMM)  was 
published1.  The  Software  Assurance 
Processes  and  Practices  Working  Group2 
has  released  several  relevant  documents, 
including  [9],  which  is  linked  to  the 
Capability  Maturity  Model  Integration  for 
Development.  In  addition,  the  Open  Web 
Applications  Security  Project  has  devel¬ 
oped  a  Software  Assurance  Maturity 
Model  for  software  security  [10].  Finally, 
the  BSI  website  at  <https://buildsecurity 
in.us-cert.gov>  contains  a  growing  set  of 
reference  materials  on  software  security 
practices. 

The  emerging  collection  of  secure 
development  techniques  arose  from 
addressing  specific  software  weaknesses. 
The  following  section  considers  three 
classes  of  software  weaknesses  as  a  way  to 
explain  the  criticality  of  software  design 
and  coding  mistakes. 

Common  Weaknesses  in  Applications 

Three  common  weaknesses — cross-site 
scripting  (XSS),  SQL  injection,  and  cross¬ 
site  request  forgery  (CSRF) — appear  in 
the  top  four  of  the  2010  CWE/SANS  list. 
Topping  the  list  is  XSS,  which  can  com¬ 
promise  a  user’s  computer  when  they  view 
a  page  on  what  they  consider  to  be  a  trust¬ 
ed  site.  Next  is  SQL  injection,  an  attacker 
technique  that  can  compromise  applica¬ 


tions  that  query  databases  (e.g.,  where 
credit  card  data  has  been  illegally  down¬ 
loaded).  Ranked  fourth  is  CSRF,  where  an 
attacker  can  masquerade  as  a  trusted  user 
of  a  web  server  only  to  upload  malicious 
data  to  that  server. 

XSS 

Web  traffic  consists  of  a  mixture  of  data 
and  script  in  HTML.  With  XSS,  the  attack¬ 
ers  objective  is  to  have  users  retrieve  a  Web 
page  from  your  server  that  contains  mali¬ 
cious  code,  say  in  JavaScript  that  the  attack¬ 
er  wrote.  The  user  trusts  your  server,  and 
their  browser  will  execute  the  malicious 
code  as  if  it  came  from  you.  This  vulnera¬ 
bility  is  a  design  error  that  allows  the 
attacker  to  get  their  input  into  your  server. 

SQL  Injection 

Weaknesses  are  often  associated  with  mal¬ 
formed  input.  The  vulnerability  risk  is 
high  when  an  application  incorporates 
user  input  into  a  service  request.  Assume 
we  have  an  application  that  displays  an 
employee  name  and  salary  after  a  user 
enters  an  employee  ID.  If  a  user  enters 
48983,  then  a  database  query  is  created  to 
retrieve  all  entries  that  satisfy  the  relation 
ID  =  48983.  An  attacker’s  objective  is  to 
see  if  the  input  routine  will  accept  values 
that  might  provide  additional  information. 
The  classic  SQL  injection  example  would 
be  equivalent  to  the  input  of  48983  or 
(1  —  1).  If  this  input  is  accepted,  then  the 
query  returns  all  entries  where  the 
ID  =  48983  or  where  1  =  1.  As  the  latter 
is  always  true,  all  employee  records  are 
returned. 

CSRF 

A  CSRF  is  sort  of  die  reverse  of  an  XSS. 


Figure  1 :  Software  Supply  Chain 


An  attacker  compromises  a  user  so  that 
the  attacker  can  masquerade  as  that  user, 
accessing  their  Web  site  and  making 
requests.  A  CSRF  that  inserts  data — com¬ 
bined  with  XSS  to  distribute  that  data — 
can  lead  to  extensive  and  devastating  con¬ 
sequences  (e.g.,  XSS  worms  that  spread 
throughout  very  large  Web  sites  in  a  mat¬ 
ter  of  minutes). 

Emerging  Secure 

Development  Practices 

Two  types  of  analysis — one  focused  on 
understanding  and  controlling  die  soft¬ 
ware  attack  surface  and  the  other  focused 
on  understanding  potential  threats  (threat 
modeling) — are  good  examples  of  SwA 
practices  that  can  be  incorporated  early  in 
the  development  life  cycle  and  that  help 
make  supply  chain  security  risk  manage¬ 
ment  more  tractable.  A  software  attack 
surface  is  a  way  of  characterizing  potential 
attack  vectors  for  compromising  applica¬ 
tion  code.  Threat  modeling  characterizes 
which  aspects  of  the  attack  surface  are 
most  at  risk  for  exploitation.  These  con¬ 
cepts  are  useful  during  development, 
deployment,  and  system  operation.  They 
help  guide  what  information  must  be 
gathered  and  how  it  can  be  best  used  to 
help  prioritize  and  mitigate  (if  not  elimi¬ 
nate)  supply  chain  security  risks. 

Attack  Surface  Analysis 

An  approach  to  managing  the  scope  of  the 
software  security  analysis  arose  from  prag¬ 
matic  considerations.  SDL  developer  Mi¬ 
chael  Howard  observed  that  attacks  on 
Windows  systems  typically  exploited  a 
short  list  of  features  such  as  open  ports, 
services  running  with  total  access  control, 
dynamically  generated  Web  pages,  and 
weak  access  controls  [11],  Instead  of 
counting  bugs  in  die  code  or  the  number 
of  vulnerability  reports,  Howard  proposed 
to  measure  the  attack  opportunities,  a 
weighted  sum  of  the  exploitable  features. 

An  attack-surface  metric  is  used  to 
compare  multiple  versions  or  configura¬ 
tions  of  a  single  system.  It  cannot  be  used 
to  compare  different  systems. 

Howard’s  intuitive  description  of  an 
attack  surface  led  to  a  more  formal  defin¬ 
ition  (in  [12]),  with  the  following  dimen¬ 
sions: 

•  Targets.  Data  resources  or  processes 
desired  by  an  attacker;  for  example,  a 
process  could  be  a  Web  browser,  Web 
server,  firewall,  mail  client,  database 
server,  etc. 

•  Enablers.  The  other  processes  and 
data  resources  used  by  an  attacker, 
such  as  Web  services,  a  mail  client,  or 
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Software  Defense  Application 

Supply  chain  risks  are  dangerous  for  software  acquired  and  utilized  by  the  defense  indus¬ 
try.  This  article  examines  significant  supply  chain  risks,  such  as  the  inadvertent  introduc¬ 
tion  of  exploitable  software  defects  during  development  and  third-party  product  tamper¬ 
ing.  This  article  squarely  puts  responsibility  on  the  acquirer  for  avoiding  supply  chain  prob¬ 
lems,  and  provides  several  techniques  that  will  assist  defense  industry  software  acquirers  in 
focusing  their  risk  mitigation.  These  methods  will  improve  software  quality,  in  turn  reduc¬ 
ing  expenses — especially  in  regards  to  exploitation  recovery  and  system  patching. 


having  JavaScript  or  ActiveX  enabled. 
Mechanisms  such  as  JavaScript  or 
ActiveX  give  the  attacker  a  way  to  exe¬ 
cute  their  own  code. 

•  Channels  and  Protocols  (Inputs  and 
Outputs).  These  are  used  by  an  attack¬ 
er  to  obtain  control  over  targets. 

•  Access  Rights.  Control  is  subject  to 
constraints  imposed  by  access  rights. 
An  attack  surface  analysis  reduces  sup¬ 
ply  chain  security  risk  in  several  ways: 

•  A  system  with  more  targets,  more 
enablers,  more  channels,  or  more  gen¬ 
erous  access  rights  provides  more 
opportunities  to  the  attacker.  An 
acquisition  process  designed  to  miti¬ 
gate  supply  chain  security  risks  should 
include  requirements  for  a  reduced 
and  documented  attack  surface. 

•  The  use  of  product  features  influences 
die  attack  surface  for  that  acquirer. 
The  attack  surface  can  define  the  op¬ 
portunities  for  attacks  when  usage 
changes. 

•  It  helps  to  focus  attention  on  the  code 
drat  is  of  greatest  concern  for  security 
risk.  If  the  code  is  well  partitioned  so 
drat  features  are  isolated,  reducing  the 
attack  surface  can  also  reduce  the  code 
drat  has  to  be  evaluated  for  threats  and 
weaknesses. 

•  For  each  element  of  a  documented 
attack  surface,  known  weaknesses  and 
attack  patterns  can  be  used  to  mitigate 
risks. 

•  The  attack  surface  supports  deploy¬ 
ment,  as  it  helps  identify  attack  oppor¬ 
tunities  diat  could  require  additional 
mitigation. 

Threat  Modeling 

Threat  modeling  is  a  part  of  Microsoft’s 
SDL  [6,  13],  but  it  is  a  general  purpose 
activity  that  can  easily  be  incorporated 
into  any  development  life  cycle.  Identified 
as  one  of  10  low-cost  suggestions  that 
improve  enterprise  security  [14],  threat 
modeling: 

•  Provides  a  business  justification  for 
security  by  mapping  threats  to  busi¬ 
ness  assets. 

•  Enables  a  thoughtful  conversation 
around  risk  and  trade-offs  during  soft¬ 
ware  development  in  an  objective, 
quantifiable  way. 

•  Encourages  a  logical  drought  process 
in  determining  an  application’s  security 
model. 

•  Lets  architects  and  developers  work 
together  to  understand  threats  at 
design  time  and  build  security  in, 
instead  of  hoping  that  the  quality 
assurance  team  can  discover  those 
threats  later  in  the  life  cycle. 


•  Helps  business  analysts  understand 
and  create  traceable  security  require¬ 
ments. 

The  approach  used  in  threat  modeling 
is  applicable  to  other  risk  assessment 
methodologies.  Data  flows  or  usage  scenar¬ 
ios  are  identified  along  with  critical  business 
assets.  A  detailed  walkthrough  of  a  data 
flow  considers  die  deployed  configuration 
and  expected  usage,  identifies  external 
dependencies  (such  as  required  services), 
analyzes  the  interfaces  to  other  compo¬ 
nents  (inputs  and  outputs),  and  documents 
security  assumptions  and  trust  boundaries 
(such  as  the  security  control  points).  The 
usage  scenarios  can  support  business  justi¬ 
fications  and  link  threats  to  the  criticality  of 
business  assets.  Such  a  walkthrough  can 
consider  adversary  motivations  (such  as  the 
criticality  of  die  data  being  handled),  in 
addition  to  die  technical  risks. 

Fuzz  Testing 

Increased  attention  on  secure  application 
software  components  has  influenced  secu¬ 
rity  testing  practices.  All  of  the  organiza¬ 
tions  contributing  to  the  BSIMM  do  pen¬ 
etration  testing,  but  there  is  increasing  use 
of  fuzz  testing.  Fuzz  testing  creates  mal¬ 
formed  data  and  observes  application  be¬ 
havior  when  such  data  is  consumed.  An 
unexpected  application  failure,  due  to  mal¬ 
formed  input,  is  a  reliability  bug  and  pos¬ 
sibly  a  security  bug.  Fuzz  testing  has  been 
used  effectively  by  attackers  to  find  weak¬ 
nesses.  For  example,  in  2009,  a  fuzz-test¬ 
ing  tool  generated  XML-formatted  data 
drat  revealed  an  exploitable  defect  in  wide¬ 
ly  used  XML  libraries.  At  Microsoft,  about 
20  to  25  percent  of  security  bugs  in 
code — not  subject  to  secure  coding  prac¬ 
tices — are  found  via  fuzz  testing  [6], 

Using  Secure  Development 
Practices  in  the  Software 
Supply  Chain 

Let’s  see  how  our  examples  of  secure 
development  practices  could  be  applied  to 
die  acquisitions  of  commercial  software 
components.  Inputs  to  diat  analysis  include 
organization-specific  information  and 
available  data  on  vendors  and  products. 
The  key  questions  are:  Has  the  developer  con¬ 


sidered  how  the  software  could  be  exploited?  and 
Has  behavior  under  unexpected  or  adverse  condi¬ 
tions  been  analysed?  The  evidence  to  answer 
those  questions  can  be  drawn  from  coding 
practices,  static  code  analysis,  common 
weaknesses  analysis,  attack  patterns  analy¬ 
sis,  threat/ vulnerability  analysis,  software 
security  testing,  and  dynamic  testing. 

Techniques  such  as  attack  surface 
analysis,  threat  modeling,  and  fuzz  testing 
could  play  multiple  roles  in  commercial 
software  acquisition. 

Assume  a  commercial  component  is 
part  of  a  larger  contracted  system  devel¬ 
opment  acquisition.  In  this  instance,  the 
commercial  components  are  selected  by 
the  primary  contractor.  Supply  chain 
analysis  could  include  examining: 

•  The  attack  opportunities  the  compo¬ 
nent  exposes  in  terms  of  features  and 
implementation  (component  develop¬ 
er,  prime  contractor,  or  independently 
developed) . 

•  The  identification  and  mitigation  of 
risks  by  the  component  developer  (e.g., 
supplier  fuzz  testing,  supplier  threat 
modeling  [or  the  equivalent],  indepen¬ 
dent  assessment,  contractor  fuzz  test¬ 
ing,  and  acquirer  fuzz  testing  as  part  of 
acceptance  and  continued  for  product 
upgrades  during  sustainment). 

•  The  criticality  of  risks  for  die  planned 
usage  (contractor  threat  modeling  as  a 
basis  for  discussions  with  the  acquirer). 

•  Risk  mitigations  (acquirer  trade-off 
decisions  with  respect  to  functionality, 
costs,  and  acceptable  risks  based  on 
contractor  threat  modeling). 

Also  note  that  development  artifacts 
should  include  documented  supply  chain 
and  threat-modeling  analysis  provided  by 
the  contractor  to  the  acquirer. 

Acquirer  Responsibilities 

Supply  chain  risks  continue  during  sus¬ 
tainment.  A  documented  attack  surface 
and  threat-modeling  analysis — provided 
by  a  vendor — would  influence  the  acquir¬ 
er’s  future  responses  to  changes  in  usage, 
threats,  or  supporting  technologies,  and 
should  be  incorporated  into  contracting 
efforts  done  during  sustainment. 

While  part  of  the  responsibility  for 
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supply  chain  assurance  can  be  outsourced 
to  a  prime  contractor,  die  supply  chain 
risks  for  individual  systems  have  to  be 
aggregated.  For  all  deployed  systems,  the 
responsibility  for  the  aggregation  of  sup¬ 
ply  chain  risks  falls  to  the  acquirer. 
Software  acquisition  has  grown  from  the 
delivery  of  standalone  systems  to  the  pro¬ 
visioning  of  technical  capabilities  integrat¬ 
ed  within  a  larger  system-of-systems  (SoS) 
context.  This  integration  extends  the  criti¬ 
cality  of  supply  chain  risk  analysis. 
Software  security  defects  in  any  of  the 
products  or  services  are  a  potential  supply 
chain  security  risk  to  all  SoS  participants. 
A  set  of  one-off  approaches  for  individ¬ 
ual  system  supply  chain  assurance  creates 
a  nearly  impossible  task  for  an  SoS. 

Summary 

A  software  supply  chain  objective  should 
be  to  incorporate  the  identification  and 
mitigation  of  likely  design,  coding,  and 
technology-specific  weaknesses  into  the 
development  life  cycle.  This  article  pro¬ 
vides  an  analysis  of  three  practices  that 
support  that  objective.  Mitigations  of 
items  on  a  CWE/SANS  Top  25  list  are 
usually  linked  to  detailed  design  or  coding 
practices,  but  mitigations  are  also  associat¬ 
ed  with  risk  analysis,  requirements,  archi¬ 
tecture,  and  testing.  This  article — and 
sources  like  the  BSI  Web  site — provide  a 
foundation  for  establishing  a  full  life-cycle 
context  for  security  improvement.^ 
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Notes 

1 .  BSIMM  was  created  from  a  survey  of 
nine  organizations  with  active  software 
security  initiatives  considered  to  be  the 
most  advanced.  The  nine  organiza¬ 
tions  were  drawn  from  three  sectors: 
financial  services  (4),  independent 
software  vendors  (3),  and  technology 
firms  (2).  Those  companies  among  the 
nine  who  agreed  to  be  identified 
include  Adobe,  The  Depository  Trust 
&  Clearing  Corporation,  EMC, 
Google,  Microsoft,  Qualcomm,  and 
Wells  Fargo. 

2.  The  group  operates  under  die  spon¬ 
sorship  of  the  DHS’s  National  Cyber 
Security  Division.  See  <https:/ /build 
securityin.us-cert.gov/  swa/ procwg. 
html>. 
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Information  Assurance  Applications  in 
Software  Engineering  Projects 

Lt.  Col.  Thomas  A.  Augustine  (Ret.)  and  Dr.  Lori  L.  DeLooze 

United  States  Naval  Academy 

Four  recent  capstone  projects  by  students  in  the  U.S.  Naval  Academy’s  (USNAJ  Department  of  Computer  Science  offer 
some  interesting  insights  into  methodologies  for  information  assurance  (LA).  This  article  looks  at  the  tasks  and  challenges  of 
each  project  and  consolidates  the  experiences  into  lessons  learned  for  designing  and  implementing  software  or  systems  that  incor¬ 
porate  the  LA  concepts  of  confidentiality,  data  integrity,  authentication,  and  system  availabilily  [1], 


One  USNA  requirement  (for  comput¬ 
er  science  or  IT  undergraduates)  is  a 
capstone  project.  Students — in  groups  of 
three  or  four  on  a  project  of  their  choos¬ 
ing — must  find  a  customer,  define  require¬ 
ments,  and  meet  key  milestone  dates  in 
providing  a  software  or  system  artifact. 
Projects  require  about  150  hours  per  per¬ 
son  and  must  be  completed  and  fully  doc¬ 
umented  within  the  15 -week  semester. 

Over  tire  past  two  years,  there  has  been 
increased  student  motivation  to  choose  IA- 
related  projects.  Like  software  or  systems 
engineering  projects  in  other  fields,  stu¬ 
dents  found  it  especially  challenging  to 
define  customer  requirements  and  meet 
expectations  and  milestones.  Faculty  use 
these  challenges  as  learning  opportunities 
by  allowing  students  to  make  their  own 
project  decisions,  even  if  poor  decision¬ 
making  leads  to  a  mid-project  failure, 
because  these  failures  will  teach  the  stu¬ 
dents  much  more  than  a  perfectly  executed 
plan.  Students  found  that  taking  on  pro¬ 
jects  in  tire  IA  field  of  study  created  addi¬ 
tional  challenges  in  subject  matter  knowl¬ 
edge,  system  design,  and  implementation. 

Team  I :  Training  Database 
with  Multi-Level  Views 

The  first  project  required  students  to 
develop  a  training  and  personnel  database 
drat  provides  proper  authentication  at  an 
undetermined  number  of  organizational 
or  data  visibility  levels  and  minimizes  rep¬ 
etition  of  data  entry  by  using  data  nor¬ 
malization.  This  group  found  the  require- 
ments-gathering  process  to  be  fairly 
straightforward,  as  the  customer  under¬ 
stood  the  concept  of  a  database  with  mul¬ 
tiple  levels  of  security.  These  requirements 
included  allowing  designated  individuals 
to  input  and  view  multiple  training  cours¬ 
es  as  well  as  providing  status  reports  to 
higher-level  managers. 

This  team  designed  die  software  widi 
an  initial  authentication  scheme  and  then 
created  a  secure  session  diat  verified  cre¬ 
dentials  before  displaying  data.  Read,  write, 
and  modify  rules  were  given  based  on  data¬ 


base  views,  combining  multiple  tables  in 
various  views.  The  database  administrator 
programmed  these  views,  which  had  the 
capability  of  providing  granular  permis¬ 
sions.  Originally,  the  team  planned  to 
hard-code  permissions  as  read  and  modify 
for  all  levels  higher  than  die  supervisor, 
meeting  the  customer  requirements. 
However,  after  initial  design  review,  they 
realized  that  diese  requirements  may  later 
change;  therefore,  the  team  redesigned 
access  control  by  giving  the  database 
administrator  the  ability  to  set  visibility  by 
level  or  by  allowing  the  overriding  of  per¬ 
missions.  This  additional  flexibility  added 
die  capability  to  produce  a  report  by  giv¬ 
ing  full  permissions  by  person,  group,  and 
supervisory  levels,  as  well  as  highlighting 
all  overridden  permissions. 

Team  2:  Emergency 
Notification  System 

The  next  project1  required  an  undeter¬ 
mined  number  of  individuals  and  organi¬ 
zations  to  receive  emergency  notification 
of  events  based  on  input  from  city,  state, 
nationwide,  or  worldwide  sensors.  Some 
events  only  need  to  be  seen  by  the  local 
emergency  services  while  odiers  required 
visibility  for  governors,  the  military,  or 
federal  officials.  Some  events  are  simply 
logged,  while  higher-priority  events  may 
require  confirmation  from  the  appropriate 
source  and  the  ability  to  forward  data  to 
higher  levels  for  additional  action. 

This  team  also  had  a  challenge  with  the 
design  and  implementation  of  permission 
and  authentication  methods.  Unlike  the 
first  group,  however,  these  students  did 
not  initially  incorporate  authentication  at 
tire  design  phase.  While  they  understood 
die  requirements  to  have  multiple  levels  of 
reporting  based  on  the  users’  position  and 
audientication,  the  team  decided  to  put 
diis  off  until  the  implementation  phase. 
Because  specifying  the  design  is  arguably 
die  most  difficult  step  in  the  software 
engineering  process,  many  students  simply 
want  to  get  started  with  the  implementa¬ 
tion  phase.  These  students  started  imple¬ 


menting  code  based  on  a  poorly  elaborat¬ 
ed  design.  They  split  up  work,  each  build¬ 
ing  separate  Web  pages  for  a  type  of 
emergency  reporting  required.  This  result¬ 
ed  in  disparate  pages  that  looked  and 
operated  differently  and  had  no  means  of 
accepting  dynamic  changes.  In  addition, 
the  team  realized  that  they  designed 
audientication  by  page  or  view  radier  than 
providing  a  consolidated,  centralized 
means  of  authentication  and  a  data  per¬ 
mission  schema. 

Though  reluctant  to  scrap  six  weeks  of 
work,  the  team  ultimately  chose  to  begin 
from  scratch  and  start  again  at  the  require¬ 
ments  phase.  At  this  point,  they  developed 
formal  interview  questions  for  the  cus¬ 
tomer  and  wrote  a  concise  statement  that 
encompassed  all  requirements.  They  dien 
took  each  sentence  or  phrase  and  turned  it 
into  a  well-defined  requirement  placed  in  a 
requirements  implementation  and  testing 
matrix.  From  this  matrix,  the  students  cre¬ 
ated  a  design  that  incorporated  every 
requirement.  These  requirements  speci¬ 
fied  authentication  and  visibility  schemas 
for  each  view.  After  further  analysis,  the 
team  was  able  to  design  a  method  for  cen¬ 
tralized  audientication  and  visibility  with  a 
small  change  to  die  database  schema. 

The  team  was  able  to  re -accomplish 
requirements  analysis  and  design  in  only  a 
week,  and  was  able  to  implement  the 
backend  database  in  anodier  week.  The 
team  admitted  that  they  had  their  doubts 
about  whether  they  could  finish  die  pro¬ 
ject  on  time,  but  were  surprised  to  see  the 
ease  of  implementing  and  testing  well- 
defined  requirements  and  design. 

Team  3:  Cybersecurity 
Competition  Framework 

This  project — stemmed  from  a  Polytech¬ 
nic  Institute  of  New  York  University 
competition — had  students  from  numer¬ 
ous  schools  downloading  various  cyberse¬ 
curity  and  digital  forensics  exercises  that 
were  timed  and  graded  for  accuracy  and 
completeness. 

USNA  students  felt  that  drey  could 
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improve  the  competition  by  designing  a 
better  interface  for  serving  and  grading 
die  cyber  challenges.  As  such,  they  set  out 
to  create  a  Web-based  software  framework 
that  served  various  scenarios  and  received 
team  responses  for  an  IA  competition. 
Requirements  included  authentication  and 
proper  visibility  of  scenarios  for  an  unde¬ 
termined  number  of  teams,  competition 
referees,  scenarios,  and  team  responses. 
Additionally,  since  they  were  creating  a 
framework  for  a  hacking  competition, 
they  had  to  design  a  system  that  main¬ 
tained  the  integrity  and  availability  of  the 
data  despite  possible  hijack  attempts  from 
less  scrupulous  teams. 

In  consultation  with  the  faculty,  stu¬ 
dents  chose  to  both  build  the  framework 
diat  was  to  serve  the  cyber  challenges  and 
create  individual  challenges  as  a  proof  of 
concept  for  their  serving  framework.  As 
such,  they  assigned  two  team  members  to 
build  the  framework,  while  two  others 
independently  built  challenges.  The  re¬ 
quirements  called  for  a  broad  range  of 
possible  cyber  challenges  including:  digital 
forensics  of  disk  images,  analysis  of  net¬ 
work  traffic,  analysis  of  software  code  vul¬ 
nerabilities,  and  the  identification  and  mit¬ 
igation  of  operating  system  and  applica¬ 
tions  security  configurations. 

Like  the  others,  this  team  started  by 
gaining  detailed  requirements  for  which 
protection  against  common  software  vul¬ 
nerabilities  was  key.  They  quickly  realized 
diat  system  security  had  to  be  built  into 
die  design  process.  Widi  diis  additional 
requirement,  they  realized  the  design 
would  be  the  most  difficult  aspect  of  their 
project  and  allocated  additional  time  for 
diis  milestone.  Before  designing  in  securi¬ 
ty,  the  team — both  to  protect  their  infra¬ 
structure  and  to  develop  challenges  for 
the  competition  framework — had  to 
understand  how  hackers  use  vulnerabili¬ 
ties  to  get  into  systems.  Each  student 
chose  to  specialize  in  specific  network, 
operating  system,  application,  and  data¬ 
base  security  techniques.  To  better  under¬ 
stand  these  techniques,  students  reviewed 
previous  coursework,  examined  DoD  and 
National  Security  Agency  (NS A)  security 
guides2,  and  interviewed  network  security 
administrators.  They  found  that  the  most 
difficult  portion  of  securing  an  applica¬ 
tion  against  hackers  is  not  the  actual 
implementation  of  a  specific  configura¬ 
tion  or  fix,  but  in  thinking  like  die  hacker 
and  predicting  how  people  will  use  poten¬ 
tial  vulnerabilities  to  disrupt  operations. 

Though  the  team  found  implementa¬ 
tion  of  the  database  and  associated  views 
to  be  relatively  trivial,  they  found  die  doc¬ 
umentation  process  to  be  challenging. 


Documentation  had  to  include  reasons  for 
dieir  design  decisions  and  security  set¬ 
tings,  so  that  future  maintainers  could  add 
features  but  still  capitalize  on  the  security 
features  built  into  die  framework. 

Students  noted  that  there  was  great 
value  in  understanding  and  implementing 
die  security  guides.  While  their  IA  course 
had  many  hands-on  experiences,  it  was 
only  through  the  course  of  this  project 
diat  they  realized  the  complexity  of  secur¬ 
ing  applications. 

Team  4:  Cyber  Defense 
Exercise 

In  this  project,  students  were  required  to 
design  and  implement  a  complete  network 
based  on  an  intricate  set  of  constraints. 
After  implementation,  students  had  to 
operate  and  defend  this  network  against 
NS  A  experts  posing  as  attackers.  Called 
die  Cyber  Defense  Exercise  [2],  the  com¬ 
petition  is  modified  annually  to  increase 
die  cybersecurity  skills  required  of  student 
participants.  Several  years  ago,  the  focus 
was  on  active  defense,  while  the  more 
recent  exercises  have  focused  on  die  trade¬ 
offs  that  need  to  be  made  between  limited 
resources,  operations  of  a  network,  securi¬ 
ty,  time,  and  expertise  required. 

Students  were  provided  with  a  40-page 
directive  spelling  out  die  rules  of  die  com¬ 
petition  along  widi  listing  die  network  ser¬ 
vices  diat  must  be  provided  during  a  week- 
long  exercise  (and  die  points  to  be  deduct¬ 
ed  if  diese  services  were  eidier  not  opera¬ 
tional  or  had  security  compromises). 
Essentially,  students  were  given  a  very 
detailed  requirements  document  with  total 
freedom  to  produce  any  design.  Though 
students  were  asked  to  turn  in  their  designs, 
referees  only  verified  diat  diey  met  bud¬ 
getary  constraints.  Cross-referencing  re¬ 
quirements  to  design  was  a  task  left  totally 
to  each  competing  student  group. 

Though  students  were  not  required  to 
gather  requirements  from  an  external  cus¬ 
tomer,  diey  did  have  to  interpret  die  direc¬ 
tive  and  design  a  complete  network  given 
die  assumptions,  constraints,  and  require¬ 
ments.  Students  were  challenged  with  cre¬ 
ating  a  design  that  could  provide  users 
with  a  number  of  services,  such  as  e-mail, 
chat,  Web,  databases,  file  servers,  and  mis¬ 
sion-specific  applications.  This  design  had 
to  remain  operational  while  withstanding 
attacks  from  NSA  network  experts  posing 
as  hackers. 

Student  team  members  had  taken  bodi 
networking  and  IA  courses,  yet  there  was 
still  a  great  deal  of  knowledge  needed  for 
die  secure  design  of  an  operational  net¬ 
work.  Students  augmented  their  knowledge 


of  secure  design  widi  NSA  security  guides, 
Defense  Information  Systems  Agency 
security  checklists3,  and  various  security- 
specific  books  and  references.  Despite 
these  numerous  references,  students  were 
still  challenged  with  consolidating  this 
information  and  meeting  die  required  con¬ 
straints.  Perhaps  die  students’  greatest  chal¬ 
lenge  was  verifying  die  security  of  dieir 
design  and  implementation,  which  was 
done  creating  a  test  environment  that  mim¬ 
icked  die  actions  of  die  attackers.  The  team 
used  security  testing  tools  like  the 
Metasploit  Framework  (which  provides 
pre-packaged  exploits)  to  test  if  the  system 
is  vulnerable  to  attack.  Students  also  used 
other  sites  like  <www.milwOrm.com>  to 
test  dieir  system  against  additional  poten¬ 
tial  exploits;  however,  the  use  of  these 
more  advanced  techniques  required  great 
experience  and  training. 

In  addition  to  the  testing  of  security, 
students  had  challenges  in  ensuring  diat  the 
tightened  security  did  not  impact  network 
operations.  The  students  found  this  to  be  a 
great  challenge.  This  balance  between  con¬ 
tinued  operations  versus  increased  security 
involves  business  case  and  risk  analysis,  a 
skill  diat  generally  requires  expertise  in 
both  network  security  and  the  mission  area 
supported  by  die  system. 

Lessons  Learned 

Through  these  student  projects,  we  can 
learn  a  number  of  security-related  lessons 
about  gaining  requirements,  as  well  as 
designing  and  implementing  IA-focused 
systems  or  software. 

Design  Authentication  and  a  Data 
Permissions  Schema  Early 

Nearly  all  application  or  system  develop¬ 
ment  requires  authentication  methods. 
Students  found  that  the  best  results  were 
achieved  by  planning  for  both  position- 
level  and  personal-level  authentication  for 
data  visibility  during  the  design  phase. 
Even  when  requirements  only  call  for  sim¬ 
ple  authentication,  customers  tend  to  ask 
for  a  layered  authentication  by  data  type, 
organizational  position,  or  data  view. 
Rework  tends  to  be  extensive  and  time- 
consuming.  Planning  for  authentication  in 
the  design  phase  of  systems  will  likely  save 
time  and  resources  in  the  long  run. 

Use  Security  Guides 

Students  found  that  despite  more  than 
100  classroom  hours  spent  learning  about 
networks  and  IA  techniques,  additional 
application-specific  information  is  re¬ 
quired  when  designing  and  developing  IA- 
focused  applications  or  systems.  The  NSA 
and  the  Defense  Information  Systems 
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Software  Defense  Application 

Through  die  lessons  learned  by  USNA  students,  this  article  is  a  refresher  for  defense 
software  developers  on  why  it  is  important  to  design  authentication  and  data  permis¬ 
sions  early,  follow  security  guides,  use  existing  techniques  for  security  testing,  do 
regression  testing  as  changes  are  made,  ensure  drat  customers  understand  security 
costs  and  tradeoffs,  recognize  the  unintended  impact  of  users  on  security,  and  thor¬ 
oughly  document  all  elements  of  security  architecture. 


Agency  produce  security  guides  for  vari¬ 
ous  operating  systems  and  applications. 
These  guides  have  been  produced  and 
tested  by  numerous  experts  and  can  com¬ 
plement  the  developers’  knowledge  to 
meet  design  specifications  for  applications 
requiring  a  cybersecurity  focus. 

Test  Applications  Against  Known 
Security  Frameworks 

Relatively  few  software  or  system  develop¬ 
ers  have  the  skills  required  to  test  system 
designs  and  implementations  against  well- 
known  attacks  using  exploits  in  systems 
availability,  data  confidentiality,  and 
integrity.  Rather  than  recreating  exploits 
drat  may  require  a  greater  effort  than  actu¬ 
ally  securing  the  system  or  application, 
system  testers  are  encouraged  to  use  exist¬ 
ing  security  testing  frameworks.  While 
tliese  testing  frameworks  can  demonstrate 
potential  holes  in  security,  they  should  be 
used  in  concert  with  secure  programming 
techniques,  design,  as  well  as  documented 
and  tested  security  techniques. 

Plan  for  Regression  Testing 

Students  working  on  tliese  projects  noted 
die  need  for  an  updated,  descriptive  test 
plan  and  follow-on  regression  software 
testing.  This  is  true  in  any  software  appli¬ 
cation,  but  tends  to  be  highlighted  in  secu¬ 
rity-focused  applications.  Security  en¬ 
hancements  are  rarely  made  in  a  single 
place.  Instead,  these  changes  are  made  in 
die  operating  system,  database  framework, 
application,  and  various  configuration 
files.  Students  found  that  a  single  change 
in  any  one  of  diese  areas  forced  regres¬ 
sion  errors  that  were  very  difficult  to 
detect  without  a  well-formulated  and 
implemented  test  plan.  Students  learned 
that  this  testing  needs  to  be  done  as 
changes  are  made,  or  it  becomes  necessary 
to  back  out  entire  blocks  of  changes  to 
find  the  root  cause  of  bugs. 

Manage  Security  Expectations 

Customers  generally  understand  those 
requirements  and  expected  outcomes  that 
are  directly  related  to  their  subject  matter 
expertise.  Through  diese  projects,  stu¬ 
dents  noted  that  customers  expect  an 
application  to  be  secure,  but  do  not  under¬ 
stand  the  resource  costs  or  operations 
tradeoffs  required  to  make  this  a  reality. 
Students  noted  the  need  to  manage  cus¬ 
tomer  security  expectations  in  the  require¬ 
ments  phase  and  later  in  the  design  phase. 
Students  believed  that  the  best  way  to 
manage  security  requirements  and  associ¬ 
ated  customer  expectations  was  to  provide 
a  security,  operations,  and  resource  matrix 
that  cross-references  security  trade-offs. 


Understand  Security  Impact  on 
Operations 

Even  after  managing  customers’  security 
expectations  and  implementing  security 
(expected  to  exceed  requirements),  stu¬ 
dents  found  that  users  can  have  die  great¬ 
est  unintended  impact  on  security.  In  test¬ 
ing  these  applications  with  actual  users  (as 
they  would  use  them),  students  found  that 
users  will  bypass  security,  in  turn  impairing 
operations  or  user-expected  procedures. 
These  user-caused  workarounds  can 
reduce  security  effectiveness  and  give  the 
application  owner  a  false  sense  of  securi¬ 
ty.  Students  learned  that  for  security  con¬ 
trols  to  remain  effective,  designers  must 
understand  existing  user  processes  and 
procedures — and  then  design  security 
architectures  around  these  or  build  them 
in  a  user-friendly  alternative. 

Document  Reasons  for  Security 
Architecture 

like  many  software  professionals,  students 
found  project  documentation  among  die 
most  challenging  processes.  As  a  learning 
tool,  students  were  required  to  make 
changes  to  projects  based  on  documenta¬ 
tion  that  eidier  they  created  or  (in  some 
cases)  was  created  by  other  student  teams. 
Though  effective  documentation  is  always 
challenging,  students  found  diis  difficulty 
was  magnified  when  trying  to  modify  secu¬ 
rity  architectures.  Ultimately,  they  noted 
that  understanding  die  security  architecture 


documentation  is  not  enough  to  effectively 
make  changes  to  security  widiout  impact¬ 
ing  operations  or  functionality.  Instead,  stu¬ 
dents  found  it  easier  to  effectively  manage 
security  changes  when  they  had  documen¬ 
tation  that  also  explained  die  reason  for 
decisions,  limitations  in  technology,  the 
state  of  the  intended  operating  system’s 
security,  and  operational  or  process  trade¬ 
offs  associated  with  security  decisions.^ 
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Notes 

1.  This  project  was  inspired  by  die  2007 
film  “Live  Free  or  Die  Hard,”  where 
terrorists  took  control  of  emergency 
services,  die  electric  grid,  and  city-wide 
traffic  signals. 

2.  For  access  to  these  guides,  visit: 
<www.nsa.gov/ia/guidance/ security 
_configuration_guides>. 

3.  See  <http://iase.disa.mil/stigs/check 
list>. 
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There  have  been  several  research  efforts  to  enumerate  and  categorize  software  weaknesses  that  lead  to  vulnerabilities.  To  con¬ 
solidate  these  efforts,  the  Common  Weakness  Enumeration  (CWE)  is  a  community-developed  dictionary  of  software  weak¬ 
ness  types  and  their  relationships.  Yet,  using  the  CWE  to  study  and  prevent  vulnerabilities  in  specific  software  projects  is  dif¬ 
ficult.  This  article  presents  a  novel  approach  for  using  the  CWE  to  organize  and  integrate  the  vulnerability  information 
recorded  in  large  project  repositories. 


Many  vulnerabilities  in  today’s  soft¬ 
ware  products  are  rehashes  of  past 
vulnerabilities.  Developers  are  often  un¬ 
aware  of  past  problems  or  they  are  unable 
to  keep  track  of  vulnerabilities  that  others 
have  reported  and  solved.  Interestingly, 
this  is  not  because  of  a  scarcity  of  infor¬ 
mation.  In  fact,  a  plethora  of  information 
about  past  vulnerabilities  is  available  to 
developers.  Most  software  development 
projects  dedicate  some  effort  to  docu¬ 
menting,  tracking,  and  studying  reported 
vulnerabilities.  This  information  is  record¬ 
ed  in  project  repositories,  such  as  change 
logs  in  source  code  version  control  sys¬ 
tems,  bug  tracking  system  entries,  and 
mailing  list  communication  threads.  As 
these  repositories  were  created  for  differ¬ 
ent  purposes,  it  is  not  straightforward 
enough  to  extract  useful  vulnerability- 
related  information.  In  large  projects, 
these  repositories  store  vast  amounts  of 
data,  oftentimes  burying  the  relevant 
information.  Therefore,  efforts  to  sum¬ 
marize  lessons  learned  from  past  vulnera¬ 
bilities  in  a  software  project  are  essentially 
non-existent.  In  the  face  of  growing  soft¬ 
ware  complexity,  it  is  even  more  critical  to 
improve  the  mental  model  of  the  software 
developer  to  sense  the  possibility  of  vul¬ 
nerability. 

The  CWE  standardization  effort  pro¬ 
vides  a  unified  and  measureable  set  of 
software  weaknesses  for  use  in  software 
assurance  activities  [1],  CWE  is  a  commu¬ 
nity-driven  and  continuously  evolving  tax¬ 
onomy  of  software  weaknesses.  Accor¬ 
ding  to  [1],  the  CWE  vision  is  twofold, 
enabling: 

•  A  more  effective  discussion,  descrip¬ 
tion,  selection,  and  use  of  software 
security  tools  and  services  that  can 
find  weaknesses  in  source  code  and 
operational  systems. 

•  A  better  understanding  and  manage¬ 
ment  of  software  weaknesses  related 
to  architecture  and  design. 

However,  the  CWE  is  often  compared  to 
a  kitchen  sink,  as  it  aggregates  weakness 
categories  from  many  different  vulnerabil¬ 


ity  taxonomies,  software  technologies  and 
products,  and  categorization  perspectives. 
While  the  CWE  is  comprehensive,  using 
its  highly  tangled  web  of  weakness  cate¬ 
gories  is  a  daunting  task  for  stakeholders 
in  tire  software  development  life  cycle 
(SDLC). 

The  unique  characteristics  of  a  weak¬ 
ness — its  preceding  design  or  program¬ 
mer  errors,  resources/locations  that  the 
weakness  occurs  in,  and  the  consequences 
drat  follow  the  weakness  (such  as  unau¬ 
thorized  information  disclosure,  modifica¬ 
tion,  or  destruction) — are  either  expressed 
together  within  a  single  CWE  category  or 
spread  across  multiple  categories.  Such 
complexity  makes  it  difficult  to  trace  the 
information  expressed  in  the  CWE  to  the 
information  about  a  discovered  vulnera¬ 
bility  in  multiple  project-specific  sources 
(such  as  a  log  of  code  changes,  source 
code  differences,  developer  mailing  list 
discussions  around  bugs,  bug-tracking 
databases,  vulnerability  databases,  and 
public  media  releases).  Therefore,  to  facil¬ 
itate  CWE  use  in  die  study  of  vulnerabili¬ 
ties,  we  have  developed  easy-to-under- 
stand  templates  for  each  conceptually  dis¬ 
tinct  weakness  type.  This  template  can 
dien  be  readily  applied  to  aggregate  and 
study  project-specific  vulnerability  infor¬ 
mation  from  source  code  repositories. 

Each  template  is  a  collection  of  con¬ 
cepts  related  to  a  single  weakness  type. 
The  concepts  are  identified  by  extracting 
and  distilling  information  from  all  relevant 
CWE  categories  for  a  particular  weakness 
type.  Since  the  concepts  in  the  templates 
provide  meaning  to  the  usage  of  certain 
words  and  sentences  that  describe  vulner¬ 
ability  information,  we  call  them  semantic 
templates. 

While  the  CWE  is  a  collection  of 
abstract  categories,  the  Common 
Vulnerability  Enumeration  (CVE)  is  an 
ever-growing  compilation  of  actual 
known  information  security  vulnerabilities 
and  exposures,  as  reported  by  software 
development  organizations,  coordination 
centers,  developers,  and  individuals  at 


large.  CVE  assigns  a  common  standard 
identifier  for  each  discovered  vulnerability 
to  enable  data  exchange  between  security 
products  and  provide  a  baseline  for  evalu¬ 
ating  coverage  of  tools  and  services  [2], 

In  this  article,  we  outline  the  process 
of  building  a  semantic  template  to  study 
the  injection  software  weakness  type.  In 
recent  times,  injection  is  the  single  most 
exploited  weakness  type.  It  occurs  upon 
failure  to  adequately  filter  user-controlled 
input  data  for  syntax  that  can  have  unin¬ 
tended  consequences  on  the  program  exe¬ 
cution.  As  stated  in  CWE-74,  a  distin¬ 
guishing  characteristic  of  the  injection 
weakness  is  that  “the  execution  of  the 
process  may  be  altered  by  sending  code  in 
through  legitimate  data  channels,  using  no 
other  mechanism”  [3],  For  example,  con¬ 
sider  a  Web  application  that  accepts  user 
input  to  dynamically  construct  a  Web  page 
that  is  instantly  accessible  to  other  users. 
Web  blogs,  guest  books,  user  comments, 
and  discussion  pages  typically  provide 
such  functionality.  If  the  user  input  that 
gets  included  in  the  dynamic  construction 
of  a  Web  page  is  not  appropriately  sani¬ 
tized  for  HTML  and  other  executable  syn¬ 
tax  (e.g.,  JavaScript),  then  active  user-cho¬ 
sen  Web  content  (such  as  redirection  to 
malicious  Web  pages)  can  be  injected  into 
the  Web  application  and  later  served  to 
other  clients  that  load  the  tainted  Web 
page  in  their  browsers.  This  instantiation 
of  the  injection  weakness  is  most  com¬ 
monly  referred  to  as  cross-site  scripting 
(XSS).  As  observed  in  CWE-79  [4],  the 
structure  of  the  dynamically  generated 
Web  page  is  altered  by  sending  code 
(HTML  and  JavaScript)  in  through  legiti¬ 
mate  user  input  channels  to  the  Web  appli¬ 
cation. 

We  also  discuss  tire  application  of  the 
injection  semantic  template  to  study  arti¬ 
facts  related  to  a  confirmed  XSS  vulnera¬ 
bility  (CVE-2007-5000,  see  [5])  in  the 
Apache  HTTP  Server  project.  For  the 
interested  reader,  we  have  previously  elab¬ 
orated  on  the  buffer  overflow  semantic 
template  in  [6] . 
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Building  a  Semantic  Template 

When  it  comes  to  security  vulnerabilities, 
we  face  an  interesting  paradox.  On  one 
end,  we  are  inundated  with  discovered  vul¬ 
nerability  information  from  its  detection 
to  its  fix.  On  the  other  end,  there  is  most 
often  a  lack  of  security  knowhow  among 
stakeholders  in  the  SDLC.  We  realize  that 
during  software  development,  especially  in 
the  implementation  stage,  the  details  a 
programmer  has  to  remember  to  avoid 
security  vulnerabilities  can  be  enormous. 
The  mere  existence  of  long  checklists  and 
guides  (such  as  the  CWE)  is  not  enough. 
To  deal  with  enormous  details,  the  use  of 
long  checklists  needs  to  be  facilitated  by 
simple  cognitive  guides  or  templates. 
Therefore,  to  effectively  and  quickly  study 
the  large  amounts  of  information  associ¬ 
ated  with  vulnerabilities,  we  ask  the  fol¬ 
lowing  four  fundamental  questions: 

1.  What  are  the  software  faults?  In  other 
words,  what  are  the  concrete  manifes¬ 
tations  of  errors  in  the  software  pro¬ 
gram  and  design  related  to  omission 
(lack  of  security  function),  commis¬ 


sion  (incomplete  security  function),  or 
operational  (improper  usage)  cate¬ 
gories  that  can  precede  the  weakness? 

2.  What  are  the  defining  characteristics 
of  the  weakness? 

3.  What  are  the  resources  and  locations 
where  the  weakness  commonly  oc¬ 
curs? 

4.  What  are  the  consequences?  In  other 
words,  what  are  the  failure  conditions 
violating  the  security  properties  that 
can  be  preceded  by  the  weakness? 
Answers  to  these  questions  are  highly 

tangled  in  current  CWE  documentation. 
For  each  major  class  of  weakness  (such  as 
injection),  a  large  number  of  CWE  cate¬ 
gories  can  be  identified  to  find  answers  to 
these  questions.  As  a  result,  a  significant 
amount  of  work  is  needed  to  identify  die 
trail  of  CWE  categories  such  that  die 
chain  of  events  that  lead  to  a  vulnerability 
can  be  reconstructed.  To  facilitate  such 
analysis,  the  creation  of  a  semantic  tem¬ 
plate  can  be  viewed  as  a  systematic  process 
of  untangling  the  CWE  categories  and 
their  descriptions  into  different  bins  that 


correspond  to  the  four  questions.  We  first 
describe  the  preparation  and  collection 
phase  of  building  a  semantic  template. 

Preparation  and  Collection 
Phase 

Selection  of  Content 

Since  the  CWE  is  continuously  evolving,  it 
is  important  to  note  drat  our  template  is 
based  on  Version  1.6  [7],  The  CWE  uses 
views  to  integrate  multiple  categorizations 
of  weaknesses  that  share  several  CWE 
categories.  We  use  the  two  most  promi¬ 
nent  views  of  the  CWE:  the  development 
view  (CWE-699)  of  CWE  categories,  suit¬ 
ed  for  practitioners  in  the  SDLC,  and  the 
research  view  (CWE-1000),  suited  for 
research  purposes  (as  it  has  a  deep  and 
abstract  hierarchical  structure). 

Extraction  of  Relevant  Weaknesses 

The  next  step  is  to  identify  the  CWE  cat¬ 
egory  that  identifies  the  weakness  of 
interest  at  the  most  abstract  level.  For  the 
Injection  weakness,  CWE-74  is  such  a  cate¬ 
gory  [3],  Referred  to  as  the  root  category, 


Figure  1:  Injection  Semantic  Template 


September/October  2010 


www.stsc.hill.af.mil  I  7 


Game-Changing  Tools  and  Practices 


SOFTWARE-FAULT 

”>AJLURE  T(f 
PRESERVE 
GENERATED  WEB 
PAGE  STRUCTURE 
*7»-87#113 
^*4*1  ttU. 


Apache  Website  CVE-2007-5000 

— ,  a  cross  site  scnpling  attack  is  posable 

NVD  CVE-2007-5000: 

a  Cross-site  scripting  (XSS)  vulnerability  in  the  mod  Jmap  module 
. -  \  allows  remote  attackers  to  inject  arbitrary  web  script  or  HTML 
NVD  CVSS  CVE-2007-5000  impact  type  : 

Allows  unauthorized  modification -  — - 

Source  code  repository  developer  fix  documentation 
Fix  cross-s»te-scnptlr>g  issue  by  escaping  the  UR! 

ensure  that  a  charset  parameter  is  sent  in  the  contenL-type 
Source  code  repository  code  difference  before  and  after  fix: 

Filet  *1 

Line  183  and  190  modifier  Ui  escape  ntiru  :n  THU: 
ap_®scape_htJBi  (r->pool ,  r->uri) - - — "  \ 


CONSEQUENCES 


RESOURCE/LOCATION 
URlX 


SOFTWARE-FAULT 

’permissive' 
wn-misT 
n*3 


file:  mod  imagemap. c  \ 

L  i  n  r?  /IBP.  modifier*  to  (coctain  an  expil.ilT-  charac.er 
ap_set_CTntent_type tr,  '’text/hcir  1 ;  cnarset  -130  sei9  PH*t 

CAPEC-63:  Simple  script  injection: 

(Experimentation)  Use  a  list  of  XSS  probe  stnngs  to  inject  scnpt  into  resources 
(Exploit)  Develop  malicious  JavaScript  that  is  injected  through  vectors  identified 
dunng  the  Experiment  Phase 

Figure  2:  Annotation  of  Information  Pieces  for  Vulnerability  Cl  12.-2007-5000  with  Concepts  of 
the  Injection  Setnantic  Template 


we  start  here  and  adopt  four  strategies  to 
gather  weaknesses  related  to  it  in  the 
CWE  development  and  research  views: 

1.  Navigate  hierarchical  relationships  of 
the  root  category  (Parent  and  Child  Of). 

2.  Navigate  non-taxonomical  relation¬ 
ships  such  as  Can  Precede,  Can  Follow, 
Peer-of  in  the  CWE  hyperlinked  docu¬ 
ment  [7], 

3.  Keyword  search  on  the  CWE  docu¬ 
ment  [7]  for  weaknesses  that  have  the 
injection  weakness  described  in  their 
primary  or  extended  description.  Key¬ 
word  search  is  followed  by  exploration 
of  Parent,  Sibling,  and  Child  categories 
of  the  discovered  CWE  category,  for 
relevance  to  the  root  category. 

4.  Visualization  [8]  of  the  root  category 
and  its  related  weaknesses  identified  by 
automatically  parsing  the  CWE  specifi¬ 
cation  available  in  XML  [1], 

While  applying  each  strategy,  use  of 
heuristics  and  some  degree  of  judgment  is 
required  on  part  of  the  subject  matter 
expert  to  include  a  CWE  category  into  the 
pool  of  relevant  weaknesses.  Details 
about  the  CWE  categories — discovered 
by  applying  our  strategies  to  gather  weak¬ 
ness  related  to  the  root  category  CWE- 
74 — can  be  found  at  <http:/ / faculty.ist. 
unomaha.edu/ rgandhi/ st/injectioncwe. 
pdf>.  Table  1  gives  some  summary  statis¬ 
tics  roughly  describing  the  scale  of  the 


work  involved.  It  speaks  volumes  about 
the  complexity  of  the  mental  model  that 
developers  need  to  be  aware  of  to  under¬ 
stand  the  consequences  of  their  coding 
and  design  decisions,  such  that  injection 
weakness  can  be  avoided.  Although  hyper¬ 
linked,  navigating  the  CWE  documenta¬ 
tion  and  various  graphical  representations 
is  tedious  and  non-intuitive.  While  differ¬ 
ent  CWE  views  help  to  accommodate 
multiple  perspectives,  it  adds  an  additional 
layer  of  complexity. 

Template  Structuring  Phase 
Separation  of  Tangled  CWE 
Descriptions 

In  dais  phase,  the  descriptions  of  the  set 
of  CWE  categories  from  the  previous 
phase  are  carefully  analyzed  for  their  cor¬ 
respondence  to  either  a  Software  Fault  that 
leads  to  injection;  defining  characteristic 
of  the  injection  Weakness-,  Resource! 
Focation  where  injection  weaknesses  occur; 
or  Consequences  that  follow  from  a  injection 
weakness.  After  these  parts  have  been  sep¬ 
arated  and  placed  in  appropriate  bins, 
well-formed  and  succinct  concepts  for  the 
injection  semantic  template  are  identified 
in  each  bin.  For  example,  by  analyzing  the 
descriptions  for  CWE-74  in  [1],  the  fol¬ 
lowing  concepts  (shown  in  quotes)  can  be 
systematically  identified  for  each  of  the 


semantic  template  conceptual  units 
(shown  in  bold). 

•  Software  Fault:  “Failure  to  sanitize 
user  input  of  syntax  that  has  implica¬ 
tions  in  a  different  plane.” 

•  Weakness:  “Elements  of  user-con¬ 
trolled  data  have  implications  in  a  dif¬ 
ferent  plane.” 

•  Resource/Location:  “User  con¬ 
trolled  input  data.” 

•  Consequences:  “Execution  of  arbi¬ 
trary  user-controlled  data,”  “Disclo¬ 
sure  of  data  and  further  exploration,” 
“Unaccounted  actions,”  “Control  of 
authentication,”  “Unauthorized  data 
recall  and  writing,”  and  “Change 
process  flow.” 

While  some  of  these  concepts  overlap 
with  the  CWE-79,  this  category  identifies 
the  following  unique  and  more  specific 
concepts: 

•  Software  Fault:  “Failure  to  preserve 
generated  Web  page  structure,” 
derived  from  CWE-79,  is  a  more  spe¬ 
cific  software  flaw  than  a  “Failure  to 
sanitize  user  input  of  syntax  that  has 
implications  in  a  different  plane,” 
which  is  derived  from  CWE-74. 

•  Resource/Location:  “Web  page” 
(output  that  is  served  to  other  users), 
which  is  a  “User  controlled  input  data” 
that  is  addressed  in  CWE-74. 

Filtering  Concepts  and  Introducing 
Abstractions 

The  CWE  categories  are  class,  base,  or 
variant  weakness,  with  class  being  the 
most  general.  Class  weaknesses  are  de¬ 
scribed  in  a  very  abstract  fashion,  typically 
independent  of  any  specific  language  or 
technology.  Base  weakness  is  also  de¬ 
scribed  in  an  abstract  fashion,  but  with 
sufficient  details  to  infer  specific  methods 
for  detection  and  prevention  of  the  weak¬ 
ness.  On  the  other  hand,  variant  weak¬ 
nesses  are  described  at  a  very  low  level  of 
detail,  typically  limited  to  a  specific  lan¬ 
guage  or  technology. 

With  the  original  intent  of  the  seman¬ 
tic  template  to  make  weakness  more 
understandable,  we  derive  the  primary 
concepts  for  software  faults  and  weakness 
characteristics  from  the  more  general  class 
and  base  CWE  categories — while  preserv¬ 
ing  traceability  to  the  CWE  categories 
(with  more  specific  variants)  using  their 
identifiers.  This  design  decision  was  taken 
primarily  to  avoid  missing  the  forest  for 
the  trees.  We  expect  it  to  be  easier  for 
developers  to  remember  a  more  generic 
model  of  the  weakness  rather  than  a 
detailed  one.  However,  in  the  case  of  the 
Resource/Location  conceptual  unit,  it  is 
not  uncommon  to  extract  concepts  in  the 


Table  1 :  Measures  Related  to  the  Collection  of  Injection  Related  ClFEs  Measures 


Measures 

Value 

Total  number  of  CWEs  relevant  to  injection 

46 

Total  number  of  relationships  among  CWEs  relevant  to  injection 

37 

Average  number  of  relationships  (inward  and  outward)  per  CWE 

1.6 

Highest  depth  of  the  hierarchy  among  CWEs  relevant  to  injection 

4  (including  root) 

Total  number  of  pages  in  the  CWE  document  relevant  to  injection 

83 
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Software  Defense  Application 

As  die  government  and  defense  sector  adopts  standards  for  tracking  and  detecting 
specific  vulnerabilities,  there  is  an  urgent  need  for  developers  to  build  software  arti¬ 
facts  to  avoid  weaknesses  that  cause  vulnerabilities  in  the  first  place.  Semantic  tem¬ 
plates  have  multiple  usage  scenarios  in  software  assurance,  such  as  to  study  past  vul¬ 
nerabilities  in  source  code  repositories,  suggest  test  cases  for  a  identified  software 
resource,  elicit  requirements  for  avoiding  weakness,  and  provide  intuitive  explanation- 
based  guidance  to  developers  when  conditions  that  lead  to  weaknesses  are  detected. 


template  from  variant  weaknesses.  For  the 
Consequences  conceptual  unit,  we  have 
discovered  that  the  concepts  extracted 
from  consequences  listed  for  class  and 
base  CWE  categories  provide  comprehen¬ 
sive  coverage  of  consequences  identified 
from  more  specific-variant  CWE  cate¬ 
gories. 

Template  Structuring  and 
Representation 

In  this  sub-task,  the  identified  concepts 
for  the  template  are  structured  and  related 
to  each  other  based  on  the  relationships 
between  their  corresponding  CWE  cate¬ 
gories.  From  this  effort,  a  highly  struc¬ 
tured  collection  of  interdependent  con¬ 
cepts  emerge  (as  shown  in  Figure  1  on 
page  17).  Each  concept  in  the  semantic 
template  of  Figure  1  includes  numbers 
that  identify  relevant  CWE  categories.  The 
semantic  template  reduces  duplication  of 
content  across  related  CWE  categories 
while  putting  them  in  the  context  of  each 
other. 

Template  Refinement  and  Tailoring 

The  template  can  be  easily  used  to  study 
vulnerability  information  gathered  from 
multiple  sources  or  reconstruct  a  success¬ 
ful  software  exploit.  Related  to  both 
CWEs  and  CVEs,  the  Common  Attack 
Pattern  Enumeration  and  Classification 
(CAPEC)  [9]  provides  a  standard  way  to 
capture  and  communicate  the  manner  in 
which  software  weaknesses  can  be  exploit¬ 
ed.  They  are  stepwise  operationalizations 
of  attacks  against  software  systems.  By 
mapping  specific  vulnerabilities  (CVEs) 
and  attack  patterns  (CAPECs)  to  the 
semantic  template,  it  is  further  refined  and 
checked  for  obvious  omissions.  In  the  fol¬ 
lowing  section,  we  describe  such  mapping 
in  the  context  of  the  XSS  vulnerability 
from  CVE-2007-5000.  We  also  expect  the 
semantic  templates  to  be  tailored  for  a 
specific  project,  product,  or  organization. 

Using  the  Semantic  Template 
to  Study  Vulnerabilities 

We  use  the  injection  semantic  template  to 
study  the  vulnerability  information  avail¬ 
able  from  multiple  project  specific  sources 
for  the  reported  XSS  vulnerability  CVE- 
2007-5000  in  the  Apache  HTTP  server. 
These  sources  include  the  CVE  vulnera¬ 
bility  descriptions;  media  reports  about 
die  vulnerability  on  the  Apache  HTTP 
server  project  public  Web  site;  change  his¬ 
tory  in  the  open  source  code  repository; 
source  code  versions  (before  and  after  the 
fix);  and  related  CAPECs  as  test  cases. 
The  semantic  template  allows  us  to  anno¬ 


tate  the  natural  language  vulnerability 
descriptions  in  order  to  understand  and 
reconstruct  the  way  the  injection  weak¬ 
nesses  occur.  The  semantic  template  also 
allows  extrapolating  or  identifying  missing 
information  (if  any). 

The  semantic  template  provides  intu¬ 
itive  visualization  capabilities  for  the  col¬ 
lected  vulnerability  information.  In  Figure 
2,  the  vulnerability  artifacts  related  to 
CVE-2007-5000  are  filled  into  the  tem¬ 
plate.  A  larger  visualization  can  be  found 
at  <http:/ / faculty.ist.uomaha.edu/ rgand 
hi/st/injectioncve.pdf>.  Figure  2  pro¬ 
vides  an  integrated  view  that  shows  how 
developers  can  effectively  reason  about 
why  the  vulnerability  occurred;  brain¬ 
storm  possible  attack  vectors  (CAPECs); 
and  discuss  the  adequacy  of  performed 
fixes.  Stakeholders  in  the  SDLC  can  con¬ 
sume  technical  details  with  relative  ease 
and  guided  explanation. 

We  expect  that  over  a  collection  of 
CVE  vulnerabilities  in  a  particular  project, 
their  mappings  to  specific  weakness  cate¬ 
gories  will  reveal  recurring  error  patterns 
and  provide  project-specific  measures  for 
identifying  the  most  prominent  CWE 
weaknesses  for  which  developers  need 
awareness  and  training. 

Synergy  with  Other  Security 

Standardization  Efforts 

The  semantic  template  provides  a  unified 
view  of  software  weaknesses  (CWE), 
actual  vulnerabilities  (CVE),  and  relevant 
attack  patterns  (CAPEC)  that  can  be  used 
to  develop  and  prioritize  risk-based  test 
cases  for  the  most  exploited  software 
flaws.  Many  source  code  static  analysis 
tool  reports  now  provide  explicit  map¬ 
pings  from  their  error  reports  to  CWE 
and  CVE  identifiers.  However,  exploring  a 
CWE  category  and  its  related  weaknesses 
(with  currently  available  textual  and  limit¬ 
ed  visualization  formats)  poses  a  signifi¬ 
cant  burden  to  the  tool  users.  To  dais  end, 
die  concepts  in  die  semantic  template 
maintain  explicit  traceability  to  CWE 
identifiers  and  hence  can  be  used  to  pro¬ 
vide  an  intuitive,  visual,  and  layered  expla¬ 
nation  to  the  tool  user  in  the  context  of 
die  discovered  flaw.  The  tool  user  can  also 


examine  the  fix  information  from  past 
vulnerabilities  to  determine  the  course  of 
action  to  take.  In  addition,  mapping  of 
attack  patterns  (CAPECs)  to  software 
faults  in  the  semantic  template  provides 
concrete  scenarios  to  test  and  justify  the 
fix  adequacy. 

With  die  availability  of  the  Malware 
Attribute  Enumeration  and  Characteri¬ 
zation  [10]  standardization  effort  and  its 
mappings  to  the  CWE,  we  expect  to  use 
the  semantic  template  to  study  what  soft¬ 
ware  flaws  most  often  contribute  to  suc¬ 
cessful  malware  behaviors  and  CAPECs. 
For  example,  the  flaws  that  precede  the 
injection  weakness  would  most  likely  con¬ 
tribute  to  the  success  of  malware  behavior 
for  delivering  a  malicious  payload. 

Currently,  die  process  of  encoding  the 
known  vulnerabilities  and  attack  patterns 
into  the  template  is  manually  performed. 
While  manual  population  of  templates  is 
scalable  for  recording  of  new  vulnerabili¬ 
ties  as  they  are  detected,  relating  past  vul¬ 
nerabilities  with  the  templates  requires 
automation.  An  empirical  study  with  the 
Apache  repository  will  be  conducted  to 
assess  the  accuracy  of  this  automated 
process. 

As  part  of  our  future  work,  we  also 
expect  to  build  associations  of  die  seman¬ 
tic  template  with  die  Knowledge  Discov¬ 
ery  Metamodel  (KDM)  [11],  The  KDM 
defines  an  ontology  for  software  assets 
and  their  relationships;  this  could  be  lever¬ 
aged  to  describe  the  software  faults  and 
resources  in  die  semantic  template  using  a 
language-independent  semantic  represen¬ 
tation.  In  turn,  the  semantic  templates 
could  provide  abstractions  and  visualiza¬ 
tions  to  enhance  the  explanation  of 
IvDM-based  software  mining  results. 

Conclusion 

The  CVE  grows  by  roughly  15  to  20  vul¬ 
nerabilities  every  day.  Each  discovered 
vulnerability  produces  several  informa¬ 
tion  pieces  extending  from  its  discovery  to 
its  fix.  With  over  600  entries  and  more 
than  20  different  views,  the  CWE  pro¬ 
vides  a  significant  body  of  knowledge  for 
classifying  and  categorizing  software 
weaknesses.  However,  it  is  a  difficult  task 
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to  use  die  CWE  for  conducting  a  system¬ 
atic  study  of  observed  vulnerabilities. 

This  article  describes  a  process  to  sys¬ 
tematically  study  software  vulnerabilities 
using  several  software  assurance  commu¬ 
nity  standards.  A  semantic  template 
enables  us  to  systematically  assimilate  the 
information  pieces  related  to  a  vulnerabil¬ 
ity.  This  integrated  information  allows  fun¬ 
damental  questions  to  be  answered: 

•  How  do  software  flaws  lead  to  a  vul¬ 
nerability? 

•  What  are  die  consequences  of  exploit¬ 
ing  die  vulnerability? 

•  How  were  they  exploited? 

•  What  resources  were  involved? 

•  How  were  they  fixed? 

•  Are  the  applied  fixes  sufficient? 

•  What  project  specific  measures  can  be 
produced  for  die  CWE  weakness  cate¬ 
gories  diat  the  vulnerability  is  related 
to? 

•  How  do  the  discovered  vulnerability 
and  its  fix  revise  our  confidence  in  the 
software  system? 

•  What  other  weaknesses  still  remain? 

•  What  steps  should  be  taken  to  prevent 
die  vulnerabilities  in  general? 

•  Can  tools  be  optimized  to  look  for  the 
discovered  patterns? 

Answering  these  questions  is  essential 
for  an  organization  to  measure  the  effec¬ 
tiveness  of  its  secure  software  develop¬ 


ment  activities  and  justify  the  correspond¬ 
ing  assurance  given  to  customers. ♦ 
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The  Balance  of  Secure  Development  and  Secure 
Operations  in  the  Software  Security  Equation 


Sean  Barnum 
The  MITRE  Corporation 

Software  security  is  about  reducing  the  risk  that  software  poses  to  those  who  use  it  or  are  affected  by  it.  This  requires  thought 
and  action  more  than  s'unply  at  the  point  of  development  or  use.  It  requires  a  more  holistic  approach,  balancing  secure  devel¬ 
opment  and  secure  operations.  The  bad  news  is  that  these  two  capable  domains  typically  do  not  interact  much  or  understand 
each  other.  The  good  news  is  that  there  are  active  ongoing  efforts  focused  on  addressing  this  gap. 


Effectively  addressing  software  security 
requires  adequately  balancing  the 
secure  development  and  the  secure  opera¬ 
tions  domains  (see  the  mechanisms  listed 
in  Table  1). 

The  objective  of  security  in  develop¬ 
ment  is  to  prevent  security  issues  in  the 
software  causing  vulnerability.  In  the  best 
case,  this  means  preventing  such  security 
issues  from  ever  entering  the  software  to 
begin  with.  This  best-case  approach  is  dri¬ 
ven  by  activities  such  as  effective  security 
training,  security  policy  definition,  security 
requirements  specification  and  review, 
secure  architecture  and  design,  and  archi¬ 
tectural  risk  analysis.  In  the  worst  case,  this 
means  at  least  preventing  such  security 
issues  from  ever  being  fielded  into  live  sys¬ 
tems.  This  later  life-cycle  approach  is  typ¬ 
ically  driven  by  activities  such  as  secure 
code  analysis,  security  testing,  and  pene¬ 
tration  testing. 

The  objective  of  security  in  operations 
is  to  prevent  security  issues  in  deployed 
systems  by  securing  their  infrastructure, 
configuration,  and  use.  So,  the  ultimate 
goal  would  be  to  have  all  operating  soft¬ 
ware  totally  free  from  vulnerability  and 
fully  secure.  Given  the  complexities 
involved  in  today’s  software  and  the  ever- 
changing  threat  landscape,  the  reality  is 
that  no  software  can  ever  be  presumed  as 
fully  secure  and  will  typically  be  under  ongo¬ 
ing  and  consistent  attack.  Beyond  the  ini¬ 
tial  security  engineering  of  software  oper¬ 
ational  deployment,  the  bulk  of  secure 
software  operations  is  about  continuous 
situational  awareness  and  incident 
response.  Recognizing  real-world  practi¬ 
calities,  it  is  focused  on  answering  the 
foundational,  ongoing  secure  operations 
questions: 

•  Are  we  being  attacked?  (Were  we 
attacked?) 

•  How  are  we  being  attacked? 

•  What  is  the  objective  of  the  attack? 

•  What  is  our  exposure? 

•  Who  is  attacking  us? 

•  What  should  we  do  to  protect  against 
these  attacks  in  the  future? 


The  commonality  between  the  secure 
development  and  secure  operations 
domains  is  the  central  role  of  understand¬ 
ing  how  adversaries  attack  software.  While 
both  domains  have  a  need  to  understand 
how  software  is  attacked,  the  specific 
needs  of  each  domain  differ  in  level  of 
abstraction  and  in  purpose — but  in  a  syn¬ 
ergistic  fashion.  The  secure  development 
domain  needs  to  understand  the  attacker’s 
perspective  in  abstract  terms  in  order  to 
improve  security  across  a  wide  range  of 
contexts,  rather  than  individual  instances. 
The  secure  operations  domain  needs  to 
understand  the  attacker’s  specific  varia¬ 
tions  of  behavior  in  gory  detail  in  order  to 
recognize  it,  understand  it,  estimate  its 
effect,  and  plan  its  mitigation.  Due  to  the 
reciprocal  balance  between  the  top-down 
perspective  of  secure  development  and 
the  bottom-up  perspective  of  secure  oper¬ 
ations,  there  is  an  opportunity  for  each 
domain  to  address  its  own  requirements  in 
such  a  way  that  also  provides  value  to  the 
other’s  primary  focus  (see  Figure  1,  next 
page). 

Given  the  differing  requirements 
between  the  two  domains  (to  characterize 
attacks  and  potentially  exchange  this 
information),  a  flexible  mechanism  is 
required  to  capture,  describe,  and  share 
knowledge  about  common  patterns  of 
attack.  One  such  mechanism  is  the  attack 


pattern  object  as  specified  and  leveraged 
by  the  Common  Attack  Pattern  Enumer¬ 
ation  and  Classification  (CAPEC),  as  out¬ 
lined  at  <http://capec.mitre.org>.  CAPEC 
is  a  publicly  available  catalog  of  attack  pat¬ 
terns  along  with  a  comprehensive  schema 
and  classification  taxonomy  intended  to 
form  a  standard  mechanism  for  identify¬ 
ing,  collecting,  refining,  and  sharing  attack 
patterns  among  the  software  community. 
Established  in  2000,  the  attack  pattern 
concept  represents  a  description  of  com¬ 
mon  attack  approaches  abstracted  from  a 
set  of  known  real-world  exploits.  While 
this  source  of  raw  data  comes  primarily 
from  the  secure  operations  domain,  attack 
patterns  today  are  primarily  a  construct 
used  by  tire  secure  development  commu¬ 
nity  to  aid  software  developers  in  improv¬ 
ing  the  assurance  profile  of  their  software. 

In  this  role,  attack  patterns  offer  the 
secure  development  community  unique 
value  in  several  areas  such  as: 

•  Representing  abuse  cases  (how  an 
attacker  would  intentionally  abuse  a 
software  system)  during  requirements 
elicitation,  specification,  and  review. 

•  Mapping  identified  threats  to  the  soft¬ 
ware’s  modeled  attack  surface  as  part 
of  threat  modeling  activities  during 
architecture  and  design. 

•  Guiding  and  prioritizing  secure  code 
analysis  during  implementation.  This 


Table  1:  Mechanisms  for  Secure  Development  and  Operations 


Mechanisms  of  Secure  Development 

•  Effective  Security  Training 

•  Security  Policy 

•  Security  Requirements 

•  Secure  Architecture  and  Design 

•  Secure  Coding 

•  Security  Testing 

•  Penetration  Testing 

•  Risk  Management 


Mechanisms  of  Secure  Operations 

•  Secure  Configurations 

•  Firewalls 

•  Proxies 

•  Intrusion  Detection  Systems 

•  Intrusion  Prevention  Systems 

•  Real-Time  Data  Monitoring 

•  Operational  Monitoring  and  Control 

•  Incident  Response 

•  Forensics 

•  Anti-Tamper  Mechanisms 
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Figure  1 :  How  Secure  Development  and  Operations  Can  Work  Together 


Attack  Patterns 
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Figure  2:  Attack  Patterns  Bridge  Secure  Development  and  Operations 


Question 

Role  of  Attack  Patterns 

Are  we  being  attacked? 

(Were  we  attacked?) 

Attack  patterns  offer  structured  descriptions  of 
common  attacker  behaviors  to  help  interpret  observed 
operational  data  and  determine  its  innocent  or 
malicious  intent. 

How  are  we  being  attacked? 

Attack  patterns  offer  detailed  structured  descriptions 
of  common  attacker  behavior  to  help  interpret 
observed  operational  data  and  determine  exactly 
what  sort  of  attack  is  occurring. 

What  is  the  objective  of  the  attack? 

Elements  of  attack  patterns  outlining  attacker 
motivation  and  potential  attack  effects  can  be 
leveraged  to  help  map  observed  attack  behaviors  to 
potential  attacker  intent. 

What  is  our  exposure? 

The  structure  detail  and  weakness  mapping  of  attack 
patterns  can  provide  guidance  in  where  to  look  and 
what  to  look  for  when  certain  attack  pattern  behaviors 
are  observed. 

Who  is  attacking  us? 

Attack  pattern  threat  characterization  and  detailed 
attack  execution  flow  can  provide  a  framework  for 
organizing  real-world  attack  data  to  assist  in 
attribution. 

What  should  we  do  to  prevent  against 
attacks  in  the  future? 

Attack  patterns  offer  prescriptive  guidance  on  solutions 
and  mitigation  approaches  that  can  be  effective  in 
improving  the  resistance  tolerance  and/or  resilience 
to  instances  of  a  given  pattern  of  attack. 

Table  2:  Attack  Patterns  Help  Answer  Questions  Regarding  Secure  Operations 


includes  identifying  specific  high-risk 
areas  requiring  greater  analysis  rigor  as 
well  as  the  most  relevant  weaknesses 
to  look  for. 

•  Identifying,  specifying,  and  prioritizing 
security  test  cases. 

•  Serving  as  attack  templates  for  pene¬ 
tration  testing  and  objective  persona 
descriptors  for  red  team  penetration 
testing. 

The  future  potential  for  CAPEC 
attack  patterns  lies  beyond  their  evolving 
and  continued  use  within  the  secure  devel¬ 
opment  community.  The  secure  opera¬ 
tions  community  can  utilize  CAPEC  to 
assist  in  situational  awareness  of  deployed 
systems  under  attack  and  aid  in  response 
and  mitigation.  Several  characteristics  of 
attack  patterns  make  them  relevant  for  the 
secure  operations  community: 

•  Attack  patterns  provide  high-level 
rather  than  simply  low-level  detailed 
patterns  of  attacks  against  software. 

•  Much  of  secure  operations  is  about 
analyzing  low-level  activity  for  patterns 
and  composing  them  into  higher  levels 
of  abstraction  to  detect,  identify,  and 
respond  to  attacks. 

•  Software  assurance  attack  patterns 
provide  a  top-down,  high-level  context 
for  both  the  method  and  the  intent  of 
attacks. 

•  Efforts  are  currently  under  way  to  for¬ 
malize  the  CAPEC  attack  pattern 
schema  in  order  to  provide  adequate 
detail  of  attacks  for  aligning  and  inte¬ 
grating  their  context  with  bottom-up 
incident  analysis  characterizations. 
Attack  patterns  offer  a  unique  and 

practical  bridge  between  the  two  domains, 
as  shown  in  Figure  2. 

Using  attack  patterns  makes  it  possible 
for  the  secure  development  domain  to 
leverage  significant  value  from  secure 
operations  knowledge,  enabling  them  to: 

•  Understand  the  real-world  frequency 
and  success  of  various  types  of 
attacks. 

•  Identify  and  prioritize  relevant  attack 
patterns. 

•  Identify  and  prioritize  the  most  critical 
weaknesses  to  avoid. 

•  Identify  new  patterns  and  variations  of 
attack. 

Through  the  use  of  attack  patterns,  it 
is  also  possible  for  the  secure  operations 
domain  to  leverage  significant  value  from 
secure  development  knowledge.  This 
enables  those  in  the  secure  operations 
domain  to  provide  appropriate  context  to 
help  answer  the  foundational  secure  oper¬ 
ations  questions  (see  Table  2). 

One  of  the  maturation  paths  currently 
under  way  for  CAPEC  involves  integrat- 
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ing  and  refining  lower-level  attack  attribut¬ 
es  and  characteristics  to  better  support 
automatable  integration  of  both  domains. 
So  far,  this  effort  has  been  focused  on 
enhancing  attack  pattern  descriptions  with 
greater  levels  of  attack  execution  flow 
detail  and  on  the  addition  of  two  new 
constructs:  Target_Attack_Surfaces  and 
Observables. 

The  Target_Attack_Surfaces  con 

struct  is  intended  to  give  a  structured 
characterization  of  the  relevant  portions 
of  the  targeted  software  that  an  attack  is 


attempting  to  exploit.  This  sort  of  detail 
can  be  valuable  within  an  operational  con¬ 
text,  assisting  in  attack  detection,  identifi¬ 
cation,  and  characterization  through  map¬ 
ping  of  observed  effects  on  target  soft¬ 
ware  assets  and  resources.  The  current 
draft  schema  (see  Figure  3)  focuses  on 
characterizing  functional  services,  proto¬ 
cols,  command  structures,  etc.  Future 
schema  revisions  should  extend  this  con¬ 
ceptual  construct  to  address  a  broader  set 
of  attack  surface  characteristics. 

The  Observables  construct  is  intend¬ 


ed  to  capture  and  characterize  events  or 
properties  drat  are  observable  in  the  oper¬ 
ational  domain.  These  observable  events 
or  properties  can  be  used  to  adorn  the 
appropriate  portions  of  die  attack  pat¬ 
terns  in  order  to  tie  the  logical  pattern 
constructs  to  real-world  evidence  of  their 
occurrence  or  presence.  This  construct 
has  the  potential  for  being  the  most 
important  bridge  between  the  two 
domains,  as  it  enables  die  alignment  of 
the  low-level  aggregate  mapping  of 
observables  that  occurs  in  die  operations 


Figure  3:  CAPEC  -  High-Level  Attack  Surface  Draft  Schema  (Figures  3  and  4  were  created  with  Altova  XMLSpy) 
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Figure  4:  CAPEC  -  Observables  Draft  Schema 
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Software  Defense  Application 

The  DoD — along  with  its  supporting  defense  industry — has  identified  cybersecurity 
as  one  of  its  top  priorities  today  and  going  forward.  The  software  security  portion  of 
this  battle  is  currently  being  fought  on  two  fronts,  secure  development  and  secure 
operations,  with  little  coordination  between  die  two.  This  article  discusses  the  objec¬ 
tives  and  activities  unique  to  each  of  these  areas  as  well  as  some  of  their  shared  com¬ 
monality  in  the  relevance  of  understanding  the  attacker’s  perspective.  Most  impor¬ 
tantly,  it  introduces  attack  patterns  as  a  resource  that  characterizes  this  commonality 
and  offers  a  practical  and  actionable  bridge  for  coordination  and  collaboration 
between  the  secure  development  and  secure  operations  communities.  An  under¬ 
standing  of  attack  patterns  and  their  relevance  to  a  unified  approach  to  software  secu¬ 
rity  should  be  requisite  knowledge  for  all  those  working  in  DoD  software. 


domain  to  die  higher-level  abstractions  of 
attacker  methodology,  motivation,  and 
capability  that  exist  in  the  development 
domain.  By  capturing  them  in  a  structured 
fashion,  the  intent  is  to  enable  future 
potential  for  detailed  automatable  map¬ 
ping  and  analysis  heuristics. 

The  current  Observables  draft  schema 
(see  Figure  4  on  the  previous  page)  adorns 
the  AttackStep,  Attack_Step_Tech- 
nique,  Attack  Step  Outcome,  and  Attack 
_Step  SecurityControl  elements  of  the 
attack  pattern  schema.  It  focuses  on  char¬ 
acterizing  specific  observable  measures, 
their  value,  their  sensor  context,  and  how 
accurate  or  easy  to  obfuscate  they  are. 
Future  schema  revisions  should  flesh  out 


the  construct  to  cover  other  relevant 
dimensions.  Changes  will  be  based  on 
input  and  collaboration  from  die  opera¬ 
tions  community  and  other  aligned  knowl¬ 
edge  standardization  efforts  needing  this 
construct  (e.g.,  Common  Event  Enumer¬ 
ation  [CEE]  and  Malware  Attribute 
Enumeration  and  Characterization 
[MAEC]). 

People  interested  in  learning  more 
about  CAPEC,  CEE,  MAEC,  and  odier 
related  knowledge  standardization  efforts 
can  gain  better  insight  and  join  in  the 
community  collaboration  efforts  by  going 
to  the  Making  Security  Measureable  Web 
site  <http://msm.mitre.org>  and  the 
Software  Assurance  Community  Re¬ 


sources  and  Information  Clearinghouse 
<https:/ /buiklsecurityin.uscert.gov/  swa>. 

Summary 

Effective  software  security  requires  a  bal¬ 
anced  approach  between  secure  develop¬ 
ment  and  secure  operations.  The  com¬ 
monality  between  these  two  domains  is 
the  central  role  of  understanding  how 
adversaries  attack  software.  CAPEC  attack 
patterns  offer  a  mechanism  for  structured 
characterization  of  common  attacks  that 
enable  a  useful  exchange  of  information 
relevant  to  both  domains,  also  aligning 
low-level  observations  to  high-level  con¬ 
texts  for  mutual  benefit. 

CAPEC  is  currently  a  resource  lever¬ 
aged  primarily  by  the  secure  development 
community,  but  there  is  an  opportunity 
and  a  strong  need  for  increased  collabora¬ 
tion  from  the  secure  operations  communi¬ 
ty.  It  will  help  shape  and  refine  CAPEC  to 
more  effectively  serve  both  communities, 
potentially  acting  as  an  integrating  bridge 
to  eventually  yield  a  more  holistic  software 
security  capability. 

We  encourage  readers  within  both 
communities  to  become  actively  involved 
and  lend  their  knowledge  and  voices  to 
our  unifying  efforts.  ♦ 


Director  of  Systems  Engineering  •  Office  of  the  Director,  Defense  Research  and  Engineering 
3040  Defense  Pentagon  •  Washington,  DC  20301-3040  •  http://www.acq.osd.mil/se 


DEPARTMENT  OF  DEFENSE  SYSTEMS  ENGINEERING 


Delivering  Innovation, 
Agility,  and  Speed 


The  Department  of  Defense  seeks  experienced  engineers  dedicated 
to  delivering  technical  acquisition  excellence  for  the  warfighter. 
See  www.usajobs.gov 


Department  of  Defense  Systems 
Engineeiing  applies  best  engineering 
practices  to 


•  Grow  engineering  capabilities  to 
address  emerging  challenges 


•  Develop  future  technical  leaders 
across  the  acquisition  enterprise 


Support  the  current  fight;  manage 
risk  with  discipline 


Champion  systems  engineering  as  a 
tool  to  improve  acquisition  quality 
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Two  Initiatives  for  Disseminating 
Software  Assurance  Knowledge 


Dr.  Nancy  R.  Mead  Dr.  Dan  Shoemaker 

SEI  University  of  Detroit  Mercy 

Education  in  software  assurance  (SwA)  is  an  essential  element  in  the  effort  to  produce  secure  code.  This  article  describes  tiro  efforts 
that  support  national  cybersecurity  education  goals:  development  of  SwA  learning  artifacts  that  can  be  integrated  into  conventional 
learning  environments  and  establishment  of  a  reference  curriculum  for  a  master’s  degree  program,  known  as  the  MSwA. 


There  is  general  recognition  that  soft¬ 
ware  engineering  practice  can  best  be 
improved  through  education.  In  fact,  the 
establishment  of  a  National  Cyberspace 
Security  Awareness  and  Training  Program 
was  among  the  three  highest  priorities  in 
[1],  which  describes  the  program’s  pur¬ 
pose  as  to  “improve  cybersecurity  knowl¬ 
edge,  and  understanding  of  the  issues” 
and  to  produce  a  “sufficient  number  of 
adequately  trained  ...  personnel  to  create 
and  manage  secure  systems.”  The  corner¬ 
stone  of  the  initiative  was  the  mandate  to 
ensure  “adequate  training  and  education 
to  support  cybersecurity  needs”  [1], 

The  aim  of  these  initiatives  was  to 
guarantee  that  SwA  practices  would  be 
embedded  in  the  day-to-day  actions  of  the 
overall  workforce  [2].  The  problem  with 
SwA  is  that  there  was  no  single  point  of 
reference  to  “guide  the  development  and 
integration  of  education  and  training  con¬ 
tent  relevant  to  software  assurance”  [3], 
That  led  the  DHS  to  publish  a  387-page 
Common  Body  of  Knowledge  (CBK), 
which  specifies  a  comprehensive  set  of 
recommended  practices  for  secure  SwA. 
These  range  from  “heavyweight  design 
methods”  to  “model  contract  language  for 
vendors”  [3],  The  problem  is  that  none  of 
these  recommendations  have  made  their 
way  into  common  use. 

The  traditional  means  of  disseminat¬ 
ing  any  kind  of  new  knowledge  into  the 
society  at-large  is  through  formally  consti¬ 
tuted  education,  training,  and  awareness 
programs  [2],  Back  in  2003,  the  National 
Strategy  recognized  that  fact  in  Action/ 
Recommendation  3-6,  which  states  that 
research  and  development  efforts  should 
be  conducted  in  die  general  area  of  secure 
SwA  in  order  to  coordinate  “the  develop¬ 
ment  and  dissemination  of  best  practices 
for  cybersecurity.”  [1], 

The  obvious  question  eight  years  later 
is,  “How  close  are  we  to  achieving  that 
goal?”  The  two  projects  discussed  in  diis 
article  are  designed  to  promote  more 
secure  software  teaching  in  higher  educa¬ 
tion.  Together,  they  represent  die  first 
attempts  to  ensure  that  die  principles  and 
practices  of  secure  SwA  knowledge  are 


embedded  in  mainstream  higher  educa¬ 
tion  processes. 

The  problem  with  SwA  knowledge  is 
drat  it  is  crosscutting  rather  dian  discipli¬ 
nary.  In  essence,  the  knowledge  base  for 
SwA  is  located  in  a  range  of  traditional 
studies  [4],  That  includes  dissimilar  CBK 
areas  such  as  software  engineering,  sys¬ 
tems  engineering,  information  systems 
security  engineering,  safety,  security,  test¬ 
ing,  information  assurance,  law,  and  pro- 

“The  two  projects  ...  are 
designed  to  promote 
more  secure  software 
teaching ...  they  represent 
the  first  attempts  to 
ensure  that  the 
principles  and  practices 
of  secure  SWA 
knowledge  are  embedded 
in  mainstream  higher 
education  processes.” 

ject  management  [4],  As  a  result,  secure 
SwA  content  might  appear  in  many  differ¬ 
ent  places  and  be  taught  in  many  different 
ways  in  conventional  education  settings. 

It  is  clearly  unacceptable  to  approach 
die  teaching  and  learning  process  in  such 
a  disjointed  way.  Therefore,  the  way  edu¬ 
cators  promulgate  secure  SwA  knowledge 
has  to  be  coordinated.  In  order  to  coordi¬ 
nate  the  teaching  and  learning  process,  a 
formal  effort  has  to  be  made  to  integrate 
“software  assurance  content  ...  into  the 
body  of  knowledge  of  each  contributing 
discipline”  [5],  There  are  two  practical  bar¬ 
riers  to  achieving  diat  outcome: 

1 .  It  is  not  clear  what  specific  knowledge 


and  skills  should  be  taught  in  each 

area. 

2.  There  are  no  validated  methods  for 

delivering  that  knowledge  once  it  has 

been  identified. 

Logically,  the  first  step  in  integrating 
new  knowledge  into  conventional  learning 
environments  is  to  identify,  relate,  and  cat¬ 
alogue  what  is  presendy  out  there. 

Project  I  -  Documenting 
Knowledge 

The  goal  of  one  project — funded  by  die 
DoD  and  conducted  at  the  University  of 
Detroit  Mercy  (UDM) — is  attempting  to 
identify  and  document  any  knowledge, 
from  any  source,  that  could  be  related  to 
SwA.  That  knowledge  came  from  all  tradi¬ 
tional  computing  disciplines,  such  as  com¬ 
puter  science,  software  engineering,  and 
information  systems.  Nevertheless  (be¬ 
sides  die  strictly  technical  areas),  the  pro¬ 
ject  also  incorporated  die  conventional 
areas  of  information  security  as  well  as  rel¬ 
evant  knowledge  from  die  behavioral  and 
social  sciences.  The  knowledge  was 
obtained  from  all  accessible  public  and  pri¬ 
vate  sector  sources. 

The  resulting  knowledge  base  is  con¬ 
tained  in  die  DoD’s  National  Software 
Assurance  Repository  (NSAR).  The 
NSAR  encompasses  and  relates  all  com¬ 
monly  accepted  practices,  principles, 
methodologies,  and  tools  for  SwA.  It  is 
managed  by  an  automated  online  knowl¬ 
edge  management  system  with  an  underly¬ 
ing  knowledge  management  system 
roughly  based  on  die  CBK;  however,  to 
ensure  the  validity  of  the  CBK  frame¬ 
work,  the  mind  map  was  fine-tuned  and 
validated  through  conducting  a  classic 
Delphi  study  using  a  panel  of  1 1  national¬ 
ly  known  secure  SwA  experts. 

The  knowledge  base  contains  as  many 
life-cycle  methodologies  and  tools  for 
assuring  software  as  could  be  identified.  It 
also  itemizes  all  related  supporting  princi¬ 
ples  and  concepts  that  are  aimed  at 
increasing  the  assurance  and  security  of 
internally  developed  and  sustained  soft¬ 
ware.  That  also  includes  products  and  ser- 


September/October  2010 


www.stsc.hill.af.mil  25 


Game-Changing  Tools  and  Practices 


vices  purchased  from  outside  vendors. 
The  knowledge  base  is  evolutionary  and 
inclusive:  As  the  literature  of  die  field 
expands  or  new  sources  are  identified,  that 
material  will  be  catalogued  and  added  to 
die  current  knowledge  base. 

Pedagogy  Development 

The  actual  purpose  of  the  UDM  project 
was  not  simply  to  gather  knowledge;  it  was 
also  to  ensure  the  teaching  of  secure  soft¬ 
ware  topics  in  all  appropriate  education, 
training,  and  awareness  settings.  In  sup¬ 
port  of  that  goal,  the  project  has  packaged 
die  contents  of  its  knowledge  base  into 
discrete  learning  modules.  These  modules 
are  designed  to  facilitate  the  efficient  SwA 
knowledge  transfer  to  all  relevant  teaching 
and  learning  settings.  As  a  result,  die  mod¬ 
ules  can  be  incorporated  into  a  wide  range 
of  teaching  and  learning  environments. 
They  are  appropriate  for  graduate,  under¬ 
graduate,  community  college,  and  even 
high  school  education,  as  well  as  in  train¬ 
ing  and  awareness  applications. 

The  modules  are  intended  to  be  sepa¬ 
rate,  standalone  learning  artifacts  capable 
of  conveying  all  of  the  requisite  know¬ 
how  for  a  given  topic.  At  a  minimum, 
each  module  can  be  delivered  in  a  con¬ 


ventional  classroom.  However,  the  mod¬ 
ules  embody  supporting  material  that  also 
allows  delivery  in  a  range  of  asynchro¬ 
nous  and  Web-enabled  learning  environ¬ 
ments.  That  flexibility  facilitates  the  effi¬ 
cient  transfer  of  new  workforce  skills  and 
practices  to  all  types  of  settings. 

Each  module  conveys  a  logical  ele¬ 
ment  of  SwA  practice.  The  entire  collec¬ 
tion  of  tliese  modules  is  mapped  to  the 
body  of  knowledge  contained  in  the 
knowledge  base,  which  is  structured  on 
the  most  commonly  accepted  model  for 
secure  SwA  practice  (the  CBK).  This 
mapping  provides  precise  guidance  about 
the  places  where  the  newly  developed 
instructional  content  fits  within  the  com¬ 
monly  accepted  understanding  of  the  cor¬ 
rect  elements  of  practical  SwA  work. 

Each  of  the  actual  teaching  modules 
incorporates  a  set  of  conventional  learn¬ 
ing  artifacts  that  are  easily  recognizable  to 
traditional  educators.  Every  module 
includes: 

1 .  A  table  of  learning  specifications. 

2.  Presentation  slides  for  each  concept 
contained  in  the  module. 

3.  An  evaluation  process. 

4.  Any  relevant  Web-enabled  supporting 
material. 


5.  A  model  delivery  system. 

There  is  also  an  accompanying  peda¬ 
gogical  methodology  for  each  individual 
learning  module.  In  other  words,  every 
module  incorporates  a  validated  set  of 
teaching  tools,  with  each  tool  being  opti¬ 
mized  to  ensure  the  maximum  knowledge 
transfer  for  all  potential  teaching  settings. 

Mapping  for  Broad-Scale  Integration 

In  order  to  ensure  integration  into  con¬ 
ventional  higher  education  curricula,  die 
UDM  project  has  formally  mapped  all  of 
its  secure  SwA  courseware  modules  to  die 
standard  set  of  computing  topics  speci¬ 
fied  for  three  of  the  five  computer  disci¬ 
plines  in  the  Computing  Curricula  2005 
standard  (CC2005)  [6].  This  standard  is  a 
joint  authorization  of  the  Association  for 
Computer  Machinery  (ACM),  IEEE,  and 
Association  for  Information  Systems. 
Since  these  are  the  three  associations  that 
are  responsible  for  developing  and  over¬ 
seeing  computing  curricula  worldwide, 
the  CC2005  can  be  considered  to  be 
exhaustively  authoritative. 

The  elements  of  secure  SwA  practice 
were  mapped  from  the  CBK  to  the  gen¬ 
erally  accepted  curricular  recommenda¬ 
tions  (as  itemized  in  CC2005).  The  aim  of 
the  mapping  process  was  to  identify 
where  specifications  for  secure  practice 
contained  in  the  CBK  fit  within  the  rec¬ 
ommendations  for  curricular  content  in 
each  of  the  disciplines  of  computer  sci¬ 
ence,  software  engineering,  and  informa¬ 
tion  systems. 

The  mapping  itself  was  a  keyword- 
based  process,  utilizing  die  terms  from 
the  curricular  requirements  contained  in 
Tables  3.1  and  3.2  of  CC2005  as  the 
search  criterion.  Where  instances  of  that 
term  were  found  in  the  CBK,  anecdotal 
analysis  was  employed  to  determine  the 
intent  of  the  term  with  respect  to  the  dis¬ 
cussion  of  secure  SwA.  Those  intents 
were  noted,  aggregated,  and  then  catego¬ 
rized  into  highly  specific  concepts  for 
secure  SwA  that  had  to  be  communicated 
along  with  the  teaching  of  each  of  the 
conventional  CC2005  curricula  elements. 
The  detailed  mapping  of  concepts  to  rec¬ 
ommendations  was  used  to  tailor  the  inte¬ 
gration  of  the  associated  secure  SwA 
teaching  module  for  supporting  or  facili¬ 
tating  the  specific  intent  of  that  term. 

The  project  provides  a  detailed  speci¬ 
fication  of  where  each  learning  module 
best  fits  within  CC2005’s  curriculum.  It 
also  provides  a  justification  for  why  die 
module  was  placed  where  it  was  in  that 
particular  curriculum.  The  justification  is 
based  on  the  mapping  between  the  mod¬ 
ule  and  the  recommended  topics  for  a 
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standard  computer  science,  software  engi¬ 
neering,  and  information  systems  curricu¬ 
lum.  For  instance,  the  project  provides 
specific  recommendations  for  the  precise 
place  in  an  information  systems  curricu¬ 
lum  where  new  secure  SwA  content  could 
be  added  to  current  testing  topics.  The 
justification  is  necessary  to  help  individual 
curriculum  designers  understand  where 
the  learning  module  should  be  placed  in 
their  curricula.  The  justification  also  facil¬ 
itates  the  integration  and  acceptance  of 
that  module  within  the  traditional  higher 
education  and  training  communities. 

Project  2  -  MSwA  Curriculum 

The  second  education  initiative  to  sup¬ 
port  the  National  Strategy  focused  pri¬ 
marily  on  development  of  a  reference 
curriculum  for  an  MSwA.  The  SEI  is 
leading  this  ongoing  education  effort  in 
support  of  the  DHS’s  National  Cyber 
Security  Division.  This  is  a  particularly 
important  focus  because  much  of  the 
body  of  knowledge  in  secure  SwA  is 
based  on  a  foundation  of  software  engi¬ 
neering  principles  and  practices.  This  pro¬ 
ject  specifies  a  set  of  topics  and  all  of  the 
attendant  prerequisite  knowledge  and 
requirements  needed  to  ensure  a  properly 
educated  SwA  professional.  It  differs 
from  the  prior  project  in  that  it  identifies 
just  the  key  knowledge  elements  required 
to  produce  a  well-educated  practitioner — 
and  structures  those  elements  into  a  com¬ 
prehensive  curriculum. 

The  curriculum  development  team 
includes  technical  staff  from  the  SEI  and 
faculty  from  a  number  of  universities, 
including  international  representation. 
The  reference  curriculum  includes  guide¬ 
lines  that  were  used  to  develop  the  cur¬ 
riculum,  prerequisites  and  proposed  out¬ 
comes,  curriculum  architecture,  a  curricu¬ 
lum  body  of  knowledge,  implementation 
guidelines,  and  a  glossary  of  terms.  A 
number  of  existing  artifacts  (including  the 
CBK),  the  recent  graduate  software  engi¬ 
neering  curriculum  guidelines  [7],  and  the 
older  SEI  reports  on  graduate  software 
engineering  education  [8,  9]  are  inputs  to 
the  project.  The  team  also  referenced  [10] 
as  needed,  as  software  engineering  knowl¬ 
edge  is  fundamental  to  SwA.  The  project 
was  inspired  in  part  by  the  DHS  Build 
Security  In  (BSI)  Web  site  <https:// 
buildsecurityin.us-cert.gov>,  which  con¬ 
tains  articles  providing  practical  advice  on 
SwA  to  practitioners.  It  is  this  practition¬ 
er  focus  that  is  central  to  the  curriculum 
development  effort.  Another  important 
resource  for  the  team  (also  inspired  by  the 
BSI  Web  site)  is  [1 1],  which  was  used 
along  with  the  previously  noted  resources 


to  identify  the  SwA  practices  to  include  in 
the  curriculum. 

In  order  to  stay  grounded,  an  invited 
review  team  for  the  curriculum  was  also 
involved  in  the  process.  In  addition,  some 
key  industry  managers  and  practitioners 
generously  agreed  to  be  surveyed  in  order 
to  help  validate  our  understanding  of  the 
desired  outcomes.  The  curriculum  also 
includes  a  detailed  list  of  knowledge  units 
and  corresponding  Bloom’s  taxonomy 
levels  [12], 

Establishment  of  a  new  degree  pro¬ 
gram  is  a  very  ambitious  undertaking.  As 
a  consequence,  the  team  expects  that 
some  universities  will  elect  to  establish 

“Our  understanding  of 
the  knowledge  that  is 
needed  to  ensure 
capable  SwA  is  beginning 
to  be  shaped  by  these 
two  projects.  In  that 
respect — and  particularly 
given  the  critical 
importance  of  secure 
software  to  the  national 
interest — they  are 
working  together  to 
advance  that  process.  ” 

tracks  or  specializations  in  SwA  within 
existing  graduate  disciplines  (e.g.,  Mas¬ 
ter’s-level  programs  in  Software  Engi¬ 
neering  [MSwE]),  rather  than  establishing 
a  whole  new  degree.  Therefore,  guidance 
is  provided  on  how  to  implement  a  track 
or  specialization,  and  sample  course  syl¬ 
labi  are  also  provided.  Team  members  at 
Monmouth  University  and  Embry- Riddle 
Aeronautical  University  developed  candi¬ 
date  implementation  strategies  for  incor¬ 
porating  curriculum  elements  at  their  uni¬ 
versities. 

In  addition  to  the  MSwA  reference 
curriculum,  this  project  also  produced  a 
set  of  sample  outlines  for  SwA  courses 
that  could  be  offered  at  the  undergraduate 
level  [13].  These  courses  might  form  an 
area  of  concentration  within  a  computer 
science  or  software  engineering  under¬ 


graduate  degree  program  for  any  prospec¬ 
tive  adopter. 

Curriculum  Transition  Plans 

There  are  a  number  of  transition  activities 
that  accompany  this  curriculum  work,  as  a 
curriculum  is  only  the  first  step  in  effect¬ 
ing  change  in  education.  The  team  has 
started  to  work  with  the  IEEE  Computer 
Society  towards  professional  recognition, 
including  a  seminar  at  the  March  2010 
Conference  on  Software  Engineering 
Education  and  Training  to  raise  aware¬ 
ness1.  The  curriculum  has  been  presented 
at  the  2010  Curriculum  Development  in 
Security  and  Information  Assurance 
workshop,  at  a  June  2010  DHS  Software 
Assurance  Working  Group  meeting,  and 
also  in  the  Information  Assurance 
Capacity  Building  Program2.  Finally,  the 
team  will  also  form  a  group  to  work  with 
and  provide  assistance  to  universities  who 
wish  to  offer  SwA  graduate  courses.  The 
team  has  also  started  tailoring  the  curricu¬ 
lum  into  course  offerings  that  would  fit  at 
the  community  college  level. 

Looking  beyond  these  near-term 
activities,  the  team  plans  to  develop  more 
extensive  faculty  development  work¬ 
shops,  course  materials,  and  course  offer¬ 
ings  in  this  area.  They  also  hope  to  work 
towards  SwA  certification  along  the  same 
lines  as  IEEE’s  Computer  Software 
Development  Professional.  There  is  an 
opportunity  for  distance  education  in  this 
area,  and  eventually  they  may  look  at  high 
school  educational  opportunities.  The 
team  feels  that  SwA  education  is  essential 
at  all  levels,  in  order  to  ensure  that  soft¬ 
ware  and  software -intensive  systems  are 
developed  with  assurance  in  mind. 

Conclusions 

Our  understanding  of  the  knowledge  that 
is  needed  to  ensure  capable  SwA  is  begin¬ 
ning  to  be  shaped  by  these  two  projects. 
In  that  respect — and  particularly  given 
the  critical  importance  of  secure  software 
to  the  national  interest — they  are  working 
together  to  advance  that  process.  Both 
projects  are  beginning  to  establish  the 
foundation  for  moving  into  the  main¬ 
stream  of  education,  training,  and  aware¬ 
ness  a  field  that  has  historically  not  been 
either  well  understood  nor  well  recog¬ 
nized. 

The  maturity  of  SwA  education  will 
have  advanced  when: 

•  MSwA  programs — and  SwA  special¬ 
izations  within  MSwE  programs — are 
widely  available. 

•  The  SwA  materials  database  is  com¬ 
monly  used  in  course  development. 

•  SwA  offerings  are  standard  elements 
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of  undergraduate  computer  science 
and  software  engineering  degree  pro¬ 
grams. 

•  The  SwA  body  of  knowledge  has  been 
codified. 

In  the  case  of  the  MSwA  curriculum 
project,  these  master’s  programs  and 
tracks  provide  an  explicit  curriculum  of 
knowledge  and  skills  necessary  to  produce 
a  well-educated  SwA  professional.  Ulti¬ 
mately,  die  curriculum  will  be  supported 
by  die  needed  course  materials  and  course 
offerings.  In  the  case  of  the  UDM  project, 
every  instructor  in  a  computer-related  dis¬ 
cipline  now  has  access  to  validated  con¬ 
tent  and  instructional  materials  that  can  be 
easily  incorporated  into  existing  courses. 

In  both  projects,  the  boundaries  and 
elements  of  die  teaching  and  learning 
process  for  SwA  education  are  clarified. 
They  are  initial  steps  in  the  long  road  to 
being  able  to  assure  the  correctness  and 
integrity  of  the  nation’s  software  with  total 
confidence.  Together,  they  create  a  direc¬ 
tion  and  foundation  on  which  the  future 
of  the  profession  can  be  built. 
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Software  Defense  Application 

Cybersecurity  has  been  an  area  of  national  interest  for  almost  a  decade.  Education  has 
been  noted  for  years — all  the  way  up  to  die  White  House — as  one  of  die  most  impor¬ 
tant  elements  in  securing  cyberspace.  Yet,  the  DHS’s  Common  Weakness  Enumeration 
[14]  documents  797  common  defects — and  die  list  is  still  growing.  That  is  due  to  cur¬ 
rent  software  engineering  practice,  which  has  generated  software  defects  at  a  relatively 
constant  rate  for  die  past  40  years.  Those  defects — according  to  a  2008  International 
Data  Corporation  survey  (see  <www.coverity.com/html/press_story65_08_04_08. 
html>) — now  cost  the  average  U.S.  corporation  $22  million  dollars  annually.  Worse, 
they  leave  DoD  systems,  as  well  those  of  all  government  and  industry,  susceptible  to 
attack.  This  article  shows  successful  educational  experiences  in  developing  concepts 
and  passing  along  the  principles  and  practices  of  secure  SwA  knowledge. 
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Notes 

1.  The  seminar  will  be  distributed  at  a 
later  time  in  the  Virtual  Training 
Environment  format. 

2.  This  is  a  faculty  development  program 
that  was  held  dais  July  at  Carnegie 
Mellon  University. 
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Web  Sites 


Software  Assurance  Metrics  and  Tool  National  Checklist  Program  repository;  Security  Content 

Evaluation  (SAMATE)  Automation  Protocol-compatible  tools  and  data  feeds;  an 

http://samate.nist.gov  official  Common  Platform  Enumeration  Dictionary;  a 

After  reading  Dr.  Yannick  Moy’s  Static  Analysis  Is  Not  Just  Common  Vulnerability  Scoring  System;  and  a  breakdown 
for  Finding  Bugs,  visit  this  DHS  National  Cyber  Security  of  Common  Weakness  Enumeration. 

Division  and  National  Institute  of  Standards  and 


Technology-sponsored  site,  brimming  with  information  on 
cutting-edge  static  analysis  tools.  The  SAMATE  Web  site 
establishes  a  methodology  for  evaluating  software  assurance 
tools  such  as  Source  Code  Security  Analyzers,  Web 
Application  Vulnerability  Scanners,  and  Binary  Code 
Scanners.  There  is  also  the  SAMATE  Reference  Dataset,  a 
community  repository  of  example  code  and  other  artifacts 
to  help  end-users  evaluate  tools  and  developers  test  their 
methods.  Finally,  you  can  learn  more  about  SAMATE’s 
Static  Analysis  Summits  and  Workshops,  where  the  software 
assurance  community  has  come  together — sometimes 
defining  the  state-of-the-art  in  software  security  tools  at 
these  gatherings. 

Evaluating  and  Mitigating  Software 
Supply  Chain  Security  Risks 

www.sei.cmu.edu/ reports/ 1  OtnO  16.pdf 

Earlier  this  year,  the  authors  of  this  issue’s  Considering 
Software  Supply  Chain  Risks  were  also  involved  in  co-writing 
this  DoD-focused  technical  report.  In  this  document,  Dr. 
Robert  J.  Ellison  and  Dr.  Carol  Woody  (this  time  with  John 
B.  Goodenough  and  Charles  B.  Weinstock)  present  an  ini¬ 
tial  analysis  of  how  to  evaluate  and  mitigate  the  risk  of  these 
unauthorized  insertions.  The  analysis  is  structured  in  terms 
of  actions  that  should  be  taken  in  each  phase  of  the  DoD 
acquisition  life  cycle:  initiation,  development,  configura¬ 
tion/deployment,  operations/maintenance,  and  disposal. 

Mids  Win  Cyber  Defense  Exercise 
(CDX) 

www.navy.mil/search/display.asp?story-id=52902 
Information  Assurance  Applications  in  Software  Engineering 
Projects  details  several  lessons  learned  for  U.S.  Naval 
Academy  (USNA)  student  capstone  projects,  including  par¬ 
ticipation  in  the  National  Security  Agency/Central  Security 
Service’s  CDX.  During  this  spring’s  10th  Annual  event,  net¬ 
work  specialists — whose  careers  are  based  around  securing 
the  government’s  most  sensitive  communication  systems — 
challenged  Service  Academy  teams,  specifically  testing  their 
ability  to  defend  computer  networks  through  projects  the 
students  designed,  built,  and  configured.  This  article  dis¬ 
cusses  the  2010  event,  chronicling  the  project  and  sharing 
interviews  with  members  of  the  USNA  Midshipman’s  win¬ 
ning  team. 

National  Vulnerability  Database  (NVD) 

http:// nvd.nist.gov 

After  reading  Studying  Software  Vulnerabilities,  you  may 
want  to  visit  this  government  repository  of  standards-based 
vulnerability  management  data.  Information  in  the  NVD 
enables  automation  of  vulnerability  management,  security 
measurement,  and  compliance.  Sponsored  by  the  DHS’s 
Cyber  Security  Division,  its  primary  resources  include  a 
Common  Vulnerabilities  &  Exposures  and  Common 
Configuration  Enumeration  search  engine;  access  to  the 


Common  Attack  Pattern  Enumeration 
and  Classification  (CAPEC) 

http:/ / capec.mitre.org 

As  outlined  in  Sean  Barnum’s  The  Balance  of  Secure 
Development  and  Secure  Operations  in  the  Software  Security 
Equation,  attack  patterns  are  a  powerful  mechanism  to  cap¬ 
ture  and  communicate  the  attacker’s  perspective  and  their 
approaches  to  exploit  software.  The  MITRE  Corporation’s 
CAPEC  Web  site  is  an  essential  resource  in  that  fight.  A 
DHS-sponsored  software  assurance  initiative,  CAPEC  pro¬ 
vides  a  publicly  available  catalog  of  attack  patterns  as  well  as 
a  comprehensive  schema  and  classification  taxonomy.  The 
Web  site  indentifies  relevant  security  requirements,  misuse, 
and  abuse  cases;  provides  context  for  architectural  risk 
analysis  and  guidance  for  security  architecture;  prioritizes 
and  guides  secure  code  review  activities;  provides  context 
for  risk-based  and  penetration  testing;  leverages  lessons 
learned  from  security  incidents;  and  helps  identify  appro¬ 
priate  prescriptive  organization  policies  and  standards. 

The  National  Strategy  to  Secure 
Cyberspace 

http://georgewbush-whitehouse.archives.gov/pcipb 
In  their  article  Two  Initiatives  for  Disseminating  Software 
Assurance  Knowledge,  Dr.  Nancy  R.  Mead  and  Dr.  Dan 
Shoemaker  discuss  the  2003  White  House  initiative  that 
listed — as  its  third  of  five  priorities — the  need  to  establish  a 
National  Cyberspace  Security  Awareness  and  Training 
Program.  At  this  Web  site,  you  can  read  the  entire  strategy, 
including  a  case  for  action,  a  letter  from  then-President 
George  W.  Bush,  as  well  as  the  sections  detailing  the  other 
four  priorities:  a  National  Cyberspace  Security  Response 
System;  National  Cyberspace  Security  Threat  and 
Vulnerability  Reduction  Program;  securing  governments’ 
cyberspace;  and  national  security  and  international  cyber¬ 
space  security  cooperation. 

Defense  Research  &  Engineering 
(DDR&E) 

www.acq.osd.mil/ ddre 

As  part  of  the  DoD,  the  DDR&E  extends  the  capabilities  of 
current  warfighting  systems,  develops  breakthrough  capa¬ 
bilities,  and  develops  counter-strategic  scientific  and  engi¬ 
neering  options.  At  this  Web  site,  viewers  can  read  reports 
prepared  for  Congress  including  the  “Strategic 
Communication  Science  and  Technology  Plan,”  learn  the 
latest  technology  news  from  DDR&E  and  other  govern¬ 
ment  entities,  and  find  out  about  their  Science,  Technology, 
Engineering  and  Mathematics  Education  and  Outreach 
program.  The  site  also  promotes  their  latest  portal, 
DefenseSolutions.gov,  which  guarantees  30  days-or-less 
response  to  ideas  for  products,  services,  prototypes,  and 
concepts  that  advance  the  military’s  missions. 
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BackTalk 


Tools  of  the  Trade 

(or  “Why  Access  Isn’t  Just  the  Name 
of  a  Database  Program”) 


This  issue  talks  about  how  tools  and  practices  change  “the 
game.”  I  am  not  sure  really  what  “the  game”  is,  but  I  cer¬ 
tainly  understand  tools  and  practices.  And — as  long  as  we  are 
talking  about  electronic  gadgets — why,  I  LOVE  tools! 

At  the  lowest  level,  a  “tool”  is  pretty  easy  to  define.  According 
to  my  handy  Merriam- Webster  Dictionary  (the  online  version),  it 
is  a  “device  that  aids  in  accomplishing  a  task.”  This  definition 
works  for  me  (pun  intended)1. 

Do  you  have  to  be  “intelligent”  to  use  a  tool?  Depends  on 
your  definition  of  “intelligence.”  Anthropologists  have  decided 
that  monkeys  are  intelligent  because  they  have  been  observed  in 
the  wild  using  sticks  to  help  dig  and  twigs  to  help  them  capture 
termites  for  food.  While  some  previous  co-workers  come  to 
mind  with  this  anecdote2,  I  would  like  to  propose  an  alterna¬ 
tive  definition  of  tool  use.  To  me,  significant  tools  alter  my 
“access.”  Let  me  elaborate. 

Prior  to  the  1980s,  computers  were  certainly  awesome 
machines.  They  allowed  users  like  me  to 
automate  processes  that  used  to  take  me 
days  (or  weeks).  My  first  personal  comput¬ 
er  allowed  me  to  organize  my  VHS  tapes, 
my  CD  collection,  play  games,  etc.  And 
then,  I  bought  a  modem.  WOW — I  was 
able  to  exchange  programs  and  data  with 
other  users!  We  had  bulletin  boards  to 
exchange  programs,  simple  newsgroups 
allowing  me  to  exchange  thoughts  ...  and  e- 
mail!  I  had  access  to  others. 

And  then  the  Internet  evolved.  Stores 
put  inventories  online.  Books  and  pictures  and  advertisements 
and  Web  sites  abounded.  Not  only  did  I  have  access  to  others,  I 
had  access  to  information.  Lots  of  it — but  too  much  to  easily 
manage. 

And  behold:  Search  engines  came  into  being!  In  just  a  few 
years,  we  replaced  saying  “I’ll  look  that  up”  with  “I’ll  google 
that.”  In  fact,  the  Merriam- Webster  online  dictionary  gives  the 
lower-case  definition  of  “google”  not  as  a  noun  (and  a  name  for 
a  search  engine),  but  as  a  transitive  verb!  So  now  I  can  google — 
and  have  access  to  useful  information. 

And,  during  these  years  when  the  Internet  was  becoming  as 
commonplace  as  indoor  plumbing,  another  driving  force  was 
shaping  our  use  of  tools:  the  cell  phone.  Remember  the  “good 
old  days”  when  you  could  leave  your  office  and  were  expected  to 
be  unreachable  for  long  periods  of  time?  You  received  paper 
messages?  Then  die  cell  phone  (and  its  diminutive  cousin,  the 
beeper)  gave  people  instant  access  to  others.  Can’t  find  them? 
Call.  Can’t  get  them  to  answer?  Leave  a  voice  mail.  Haven’t 
responded  to  voice  mail  yet?  Txt  them3! 

And,  I  must  confess  that  I  did  not  stop  widi  the  cell  phone: 
I  use  both  an  iPhone  and  an  iPad.  Never  thought  I  would — after 
all,  I  just  wanted  my  phone  to  make  and  receive  phone  calls.  But 
once  I  tried  it,  I  was  hooked.  I’m  able  to  browse  the  Internet 
pretty  much  anywhere,  anytime.  Somebody  wants  to  know  the 
name  of  Judy  Garland’s  stunt  double  during  the  “Wizard  of 
Oz”?  No  problem:  Snap  out  the  phone,  hit  Google  Search,  and 
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find  out4.  And  my  iPad  is  even  more  addicting.  I  have  about  20 
books  loaded  on  it,  and  can  use  it  anywhere.  If  I  desperately  need 
Internet  access,  it  has  3G  capability — so  that  I  don’t  look  like  a 
TOTAL  geek5  with  an  iPad  in  one  hand  and  an  iPhone  in  the 
other.  I  now  have  instant  access  to  useful  information  combined 
with  instant  access  to  others.  Anytime,  almost  anywhere.  In  fact, 
when  I  am  driving  home  to  visit  my  folks,  I  frequently  check  my 
phone  to  see  what  kind  of  coverage  area  I  am  in.  If  I  don’t  see 
any  bars  of  coverage,  I  compulsively  check  frequently  until  I  am 
in  range  again.  And  wonder:  Was  anybody  trying  to  reach  me?  We 
have  become  so  dependent  on  our  tools  that  we  can’t  stand  being 
out  of  access! 

I  used  to  tell  the  story  about  a  boss  I  had  many,  many 
years  ago.  The  rest  of  us  were  updating  to  new  dual-core 
Pentium  machines,  a  new  operating  system,  and  we  were 
putting  in  a  T1  line  for  really  high-speed  Internet  access. 
And  we  got  to  thinking  about  our  boss.  A  few  of  us 
made  the  suggestion  that  perhaps — to 
increase  office  productivity — we  should 
give  him  a  computer  running  MS-DOS 
3.1,  Internet  access  via  a  Hayes  300  Baud 
Smartmodem,  and  a  16-color  640x200 
Color  Graphics  Adapter  monitor.  It 
might  not  have  speeded  up  his  access  to 
us,  but  it  would  certainly  increase  our 
productivity  by,  oh,  say  1,000  percent: 
His  constant  barrage  of  almost  totally 
useless  e-mails  would  slow  down,  and  we 
could  do  real  work. 

Tools  are  work  multipliers.  They  are  supposed  to  permit  you 
to  do  more  in  a  limited  time,  and  are  supposed  to  make  your  life 
easier  and  more  productive. 

What  tools  do  you  use?  How  well  do  you  use  them?  Does 
your  use  of  die  “tools  of  your  trade”  hinder  others?  Are  you  get¬ 
ting  a  Hayes  300  Baud  Smartmodem  for  Christmas? 

— David  A.  Cook,  Ph.D. 

Stephen  E  Austin  State  University 
<cookda@sfasu.edu> 

Notes 

1.  Oddly  enough,  die  very  first  definition  I  got  when  googling 
“tool”  was  from  Urban  Dictionary:  “One  who  lacks  the  men¬ 
tal  capacity  to  know  he  is  being  used.  A  fool.  A  cretin. 
Characterized  by  low  intelligence  and/or  self-esteem.”  I’ll 
save  diis  definition  for  another  column  at  a  later  date. 

2.  No  names,  but  if  you  looked  here,  you  were  worried  I  was 
going  to  mention  you,  right? 

3.  While  dictionaries  do  not  yet  define  “txt”  as  a  word,  it  is  inter¬ 
esting  to  note  that  Microsoft  Word  did  not  flag  it  as  mis¬ 
spelled! 

4.  Bobbie  Koshay.  Found  it  on  my  first  try,  using  my  iPhone,  at 
<http://thewizardofoz.info>.  Also  note  that  Caren  Marsh- 
Doll  also  helped  out  with  blocking  and  camera  tests. 

5.  Yeah — I  already  know.  Too  late.  Don’t  e-mail. 
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to  enabling 
the  nation’s 

critical  infrastructure. 
To  ensure  the  integrity  of  that 
infrastructure,  the  software  that  controls 
and  operates  it  must  be  secure  and  resilient. 


Software  Assurance  Community  Resources  and  Information  Clearinghouse 
provides  collaboratively  developed  resources.  Learn  more  about  relevant 
programs  and  how  you  can  become  involved. 

https://buildsecurityin.us-cert.gov/swa/ 

Security  must  be  ‘built-in”  and  supported  throughout  the  lifecycle. 

Visit  https://buildsecurityin.us-cert.gov  to  learn  more  about  the  practices  for 
developing  and  delivering  software  to  provide  the  requisite  assurance. 

Sign  up  to  become  a  free  subscriber  and  receive  notices  of  updates. 


The  Department  of  Homeland  Security  provides  the  public-private 
collaboration  framework  for  shifting  the  paradigm  to  software  assurance. 


Crosstalk  thanks 
the  above 
organizations  for 
providing  their  support. 


